How do security teams spot malicious activity after a legitimate login?

Why This Matters for Security Teams

A legitimate login is not a clean bill of health. Modern intrusions often begin with valid credentials, then move through OAuth consent, device enrolment, token reuse, and data access that looks “allowed” in isolation. That is why security teams need correlation across identity, endpoint, SaaS, and cloud logs, not just authentication success. The risk is especially high where non-human identities and third-party integrations are involved, as shown in The State of Non-Human Identity Security, which reports that only 1.5 out of 10 organisations are highly confident in securing NHIs.

Login telemetry answers only one question: did the account authenticate? It does not answer whether the actor behind the session is behaving normally, whether the token has been abused laterally, or whether the session is being used to stage privilege escalation. A success event can even reduce scrutiny if defenders treat it as evidence of legitimacy. Current guidance suggests the more reliable indicators are post-authentication anomalies such as unusual consent scopes, impossible travel, atypical tool access, and data movement that departs from baseline behaviour. In practice, many security teams encounter the abuse only after exfiltration or tenant-wide abuse has already started, rather than through intentional detection design.

How It Works in Practice

The practical model is to treat successful authentication as the beginning of analysis, not the end. Teams build detections that join identity provider events with SaaS audit logs, endpoint telemetry, cloud activity, and privileged access records. That correlation is what exposes the chain: a valid login, followed by token issuance, followed by a new device registration, followed by broad file enumeration or mailbox access. The NIST Cybersecurity Framework 2.0 reinforces this kind of continuous monitoring approach, while the NHIMG CI/CD pipeline exploitation case study illustrates how legitimate automation can be abused after the first foothold.

• Baseline normal working hours, source geographies, device posture, and application sequence for each identity.
• Alert on sudden file spikes, unusual download volume, or access to repositories outside the user’s normal job function.
• Flag new OAuth grants, especially when an app requests broad mailbox, drive, or directory permissions.
• Correlate session age, token reuse, and device enrolment to identify persistence after a legitimate login.
• Compare behaviour across applications, because a single SaaS log often hides the full attack path.

For non-human identities, the same logic applies but with a different baseline: API calls, pipeline actions, and service-to-service patterns must be monitored as workload behaviour rather than human activity. The Emerald Whale breach is a useful reminder that cloud and identity signals can only reveal the full sequence when they are analysed together. These controls tend to break down in highly automated environments with shared service accounts and weak application logging because the post-login trail is too fragmented to reconstruct reliably.

Common Variations and Edge Cases

Tighter correlation often increases alert volume and engineering overhead, requiring organisations to balance detection fidelity against operational noise. That tradeoff is real, especially in enterprises with many SaaS tools, delegated admin roles, and federated identity sources. Best practice is evolving, but current guidance suggests starting with the highest-risk patterns: broad consent grants, first-time device enrolment, off-hours access, and data egress from sensitive repositories or mailboxes.

One important edge case is that not every post-login anomaly is malicious. Travel, shift work, incident response, and migration activity can all look suspicious unless the detection stack understands business context. Another edge case is adversaries using “low and slow” access to stay under thresholds, which is why static rules alone are rarely sufficient. Correlation must be paired with time-window tuning and identity risk scoring. NHIMG research also shows how quickly compromise becomes durable when secrets are not rotated, so log-based detection should be paired with response actions that revoke sessions, rotate credentials, and remove newly granted consent. There is no universal standard for this yet, but the operational goal is clear: detect the behaviour that follows the login, not the login itself.

Related resources from NHI Mgmt Group

• How should security teams recover GitHub environments after a compromise?
• How should security teams recover identity provider configurations after an incident?
• Why are NHIs a critical concern for security teams?
• What steps should security teams take to prevent Shadow AI risks?