Look for outlier API behavior, especially from a principal that normally has a narrow activity pattern. In this incident, suspicious signals included key creation from an unusual IP, no recent history of CLI use, and hundreds of security group ingress changes. A principal that suddenly starts enumerating services and issuing non-read API calls deserves immediate investigation.
How compromised IAM principals reveal discovery activity
Discovery is usually visible as a shift from narrow, routine usage to broad enumeration. A compromised principal often begins touching services, regions, security groups, and metadata that were previously absent from its history. The strongest clue is not any one API call, but the mismatch between the principal’s normal pattern and the new behavior.
In AWS, discovery tends to show up as describe, list, and inspect activity that broadens the attacker’s view of the account. When that activity is paired with creation or modification calls, especially around network controls, it often means the principal is being used to map the environment before deeper action.
Useful signals include a principal that suddenly starts enumerating resources across multiple services, calling APIs it has never used before, or generating a burst of non-read actions after a long quiet period. If the identity has no prior CLI history and then begins operating from a new source IP or new user agent pattern, the change in access path matters as much as the API mix.
Why the activity pattern matters more than a single API
Discovery through a compromised principal is rarely a single event. Attackers typically test what the principal can see, what it can change, and how far they can move without triggering obvious denial or lockout. That is why a narrow principal suddenly issuing security group edits, key creation, or permission-sensitive calls is more concerning than routine read-only inventory collection.
The operational question is whether the principal’s behavior still fits its stated purpose. A deployment role, automation user, or service principal should not normally behave like an interactive investigator. Once the activity pattern becomes inconsistent with the role, the principal itself becomes the investigation pivot, not the specific service being touched.
For practical triage, compare the current session against historical baselines for source IP, time of day, CLI versus console use, service mix, and write activity. A large jump in breadth, frequency, or privilege use is often the earliest reliable indicator that the principal is being repurposed for attacker discovery.
What the discovery phase usually looks like in AWS logs
In AWS, attacker discovery commonly surfaces as broad environment probing: listing IAM-related objects, enumerating compute and network resources, checking security boundaries, and identifying where higher-value access may exist. The pattern often expands from observation to modification once the attacker confirms the principal has enough permission to continue.
When you see hundreds of ingress changes, unexpected key creation, or non-read calls from a principal with no recent CLI usage, treat that as more than noisy administration. Those events suggest the actor is not just learning the environment, but actively preparing it for subsequent access, persistence, or lateral movement.
Baselining matters because discovery often stays within legitimate API families. The clue is the combination of sequence, volume, and novelty: an old principal, a new source, unfamiliar services, and actions that do not fit prior behavior. That combination is what makes the discovery phase detectable.
Risk and Threat Considerations
Compromised principals used for discovery are dangerous because they let an attacker learn the environment using authorized access paths, which can delay detection and broaden later impact. The same identity that starts with reconnaissance can quickly become the vehicle for persistence, privilege escalation, or network exposure.
Failure mechanism: The attacker inherits the principal’s existing trust, then uses enumeration and configuration changes to map reachable services, identify weak boundaries, and test what the account can modify without immediate alarms.
Impact: Early discovery increases the chance of follow-on compromise, because the attacker can select high-value targets, avoid obvious controls, and stage changes that make later containment harder.
Practitioner Guidance
What to verify: Compare the principal’s current source IP, client type, and API mix against its historical baseline. If the account has no prior CLI pattern and suddenly produces broad enumeration or write-heavy activity, prioritize containment over further behavioral analysis.
Decision rule: If the principal is touching security controls, creating access material, or changing network boundaries, assume the discovery phase has already progressed beyond simple probing. At that point, preserve logs, revoke or quarantine the credential path, and review every action taken in the session.
Practitioner takeaway: The most useful signal is not “suspicious API traffic” in the abstract, but a principal whose behavior no longer matches its normal job, access path, or risk envelope.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
