In real incidents, the attacker doesn’t “break” access: they use it. The difference between a scare and a major incident is often whether you quickly detect the abuse of a legitimate identity (user, role, managed identity, service account) before it turns into persistence, exfiltration, or sabotage.
Useful detection is not a list of loose rules. It is understanding the operational context (what each identity does, when, and from where) and watching for deviations with logs you already have: CloudTrail, Azure Activity Logs, and GCP Audit Logs. From there, you can level up with behavior, but without relying on complex tools to get results.
What usually goes wrong: valid credentials, invalid context
The most common pattern in enterprises is “the right access for the wrong person.” A legitimately issued token (SSO, OAuth, STS, federation) is reused from a different environment: another network, another country, another automation, or outside business hours. The IAM policy can be impeccable and the abuse still happens if no one is watching how the identity is used.
In cloud, this is amplified with non-human identities: managed identities in Azure, service accounts in GCP, assumed roles in AWS, CI/CD accounts and workloads. A service account that normally reads a bucket can start enumerating IAM or calling KMS APIs. The permission may exist “for historical convenience,” and the abuse signal is in the pattern change, not in a deny.
Real consequence: the attacker avoids the noise of malware and moves with APIs. When the team detects “something odd,” often keys have already been rotated, new roles created, or firewall rules touched. That’s why the operational goal is to detect early out-of-context use, not to “confirm” the compromise when there is already impact.
Early signals that do show up in logs (and that people ignore)
Useful signals are usually boring: API calls and metadata. The key is correlating identity + action + origin + time + resource. If you only look at “login failures,” you’ll miss the abuse because many times there is no failure: there is success.
Some signals that in corporate environments repeat over and over:
- Anomalous use of tokens or sessions: sessions longer or more frequent than normal, or multiple parallel sessions from different origins for the same identity. In AWS you see it with repeated AssumeRole / GetCallerIdentity and a strange sessionName pattern; in Azure with sign-ins and operations from the same principal with IPs that don’t match; in GCP with serviceAccountToken audit and chained API calls.
- Sudden changes in access patterns: identities that never list resources start enumerating (IAM, Storage, Key Vault/KMS/Secrets). This is usually reconnaissance to prepare exfiltration or escalation, and it usually happens before “the big action.”
- Out-of-context API calls: administrative actions from runtime identities (for example, an app managed identity that suddenly makes changes in RBAC or policies). In enterprises this shows up when an identity is “reused” for speed and no one documents the real scope.
For these signals not to stay theoretical, you need a reference for normality. You don’t need an ML model: simple baselines per identity are enough (top actions, top resources, time windows, usual IPs). When an identity breaks its baseline, treat it as a security event even if authentication is valid.
How to do it in practice with CloudTrail, Azure Activity Logs, and GCP Audit Logs
Most organizations already have the logs, but instrumented poorly: without sufficient retention, without centralization, or without the fields needed to investigate. The first “quick win” is to ensure identity and control plane events are complete and arrive in a searchable place.
In AWS, prioritize CloudTrail for management events and record data events where it hurts (S3, Lambda) if the risk justifies it. In Azure, combine Azure Activity Logs (control plane) with Sign-in logs and Audit logs from Entra ID to understand authentication and operations. In GCP, enable and centralize Admin Activity, Data Access (when applicable), and IAM/Service Accounts logs in Cloud Audit Logs.
A concrete example (AWS) to detect abuse of assumed roles is to filter events where the role is assumed from an unusual provider or context and, in addition, IAM enumeration actions appear shortly after. Typical signals in CloudTrail:
- AssumeRole / AssumeRoleWithWebIdentity with generic “sessionName”: when the sessionName stops resembling your convention (pipeline, app, team) and becomes random or “admin,” it often correlates with manual use or external tooling. It’s not proof, but it’s a cheap high-value signal.
- Spike of List* and Get* against IAM, Organizations, KMS: in real investigations, reconnaissance shows up as an API “sweep.” If that identity rarely touches IAM and suddenly does ListUsers, ListRoles, GetAccountAuthorizationDetails, you have an early window before it creates persistence.
Validate that your instrumentation is correct by doing an operational verification, not a checklist: execute a controlled action (for example, assume a role and list roles) and verify that in the centralized log you can see who (principal/role), from where (source IP / user agent), when, and what (eventName + resource). If any of these is missing, detection will be blind when you need it.
Static rules vs behavior-based detection: real trade-offs
Static rules work well for very specific things (for example, “a new access key was created,” “a policy was changed,” “Owner was assigned”). The problem is that identity abuse often moves in the gray zone: allowed actions, repeated at a different rate or against different resources. There a binary rule falls short or generates too much noise.
Behavior-based detection doesn’t need to be sophisticated to provide value: it’s enough to measure deviations from normal per identity or per workload type. In enterprises, this reduces false positives when there are many legitimate changes (deploys, migrations), because you don’t alert on “any ListBuckets,” but on “ListBuckets from an identity that never does it and from an anomalous location.”
A common mistake is trying to “cover everything” from day one with dozens of rules. The result is usually alert fatigue and abandonment. It’s better to pick 5–8 high-signal detections that can be investigated in under 15 minutes with available data (identity, IP, user agent, resource, time correlation). If investigating takes hours because logs or context are missing, the alert will die in the queue.
Common mistakes when investigating and how to avoid losing the containment window
When an identity alert fires, time is lost on two things: confirming whether it is “normal” and deciding what to cut without taking down the business. If your organization has no conventions (session names, workload tags, service account ownership), every investigation starts from scratch and the containment window closes.
There are two very common anti-patterns. The first is assuming that “if MFA is enabled, we’re fine”: MFA reduces certain risks, but it doesn’t prevent token theft, abuse of valid sessions, or compromise of service accounts. The second is treating non-human identities like users: a managed identity doesn’t “log in,” but it does operations; if you only look at authentication, you won’t see the abuse.
To speed up investigation, prepare in advance a minimum of context and questions you can answer with logs:
- What should that identity do under normal conditions? If there is no baseline (even a manual one: top 10 APIs and resources), you’ll end up deciding by intuition. In real incidents, that intuition often fails when there are deployments or after-hours tasks.
- From which networks/locations is it reasonable? An unusual geolocation or an unexpected ASN doesn’t convict by itself, but when they coincide with out-of-profile actions they are a strong signal. If your company uses centralized internet egress, the IP “changes” less; if it uses SaaS/remote workforce, you’ll need better contextualization.
- What irreversible action happened first? Identify the first change with impact (policy attached, role created, secret read, firewall modified). In cloud, the attacker often chains: reconnaissance → access to secrets → persistence. Cutting after persistence is more expensive.
If during investigation you find you can’t answer these questions with your current logs, that’s not “bad luck”: it’s a detection gap. Document the gap and turn it into an operational improvement (fields, retention, centralization, conventions) before the next case is real.
Recommendations for corporate environments
Detecting identity abuse in time depends less on a specific tool and more on operational discipline: complete control plane logs, context per identity, and detections focused on deviations. The most valuable signals are usually out-of-normal token/session use, abrupt pattern changes, and API calls that don’t fit the principal’s real role.
As quick wins without excessive complexity, prioritize: centralizing and retaining CloudTrail/Azure Activity Logs/GCP Audit Logs with the required fields, creating simple baselines per identity (actions, time windows, origins), and keeping a small number of high-signal detections that can be investigated quickly. If an alert can’t be validated with available data in minutes, the problem is not the alert: it’s the instrumentation and context.
In corporate environments, the practical goal is to gain a containment window before there is persistence: identify early the “invalid context” even if the credentials are valid, and have enough traceability to decide to cut access with the least possible impact on the business.
Interested in Cloud Security?
Technical analysis, hands-on labs and real-world cloud security insights.