What are the signs that an AWS incident is moving from reconnaissance to persistence?

What the recon-to-persistence shift looks like in AWS

The change usually shows up as a move from read-heavy discovery into write actions that alter identity or access state. A suspicious actor may begin by mapping users, policies, roles, instances, and logging, then switch to creating or modifying users, access keys, policies, or trust relationships. The key signal is not one call, but a sequence that turns observation into control.

That sequence matters because AWS reconnaissance often uses the same management plane that later enables persistence. In CloudTrail, the early phase is dominated by enumeration, while the later phase introduces changes that can survive a password reset or a simple session kill. Analysts should read the sequence in context, not as isolated API noise.

When you see discovery followed by access changes, the working assumption should be that the actor is testing what exists, then selecting the easiest durable foothold. For deeper context on identity-driven attack patterns and why persistence often follows credential abuse, see Identity Threat Detection and Response (ITDR) Guide and The 52 NHI Breaches Report.

Typical transition points include creating a user, attaching or editing policies, creating access keys, altering password policy, adding inline permissions, or changing a role trust policy. In AWS, those actions can be enough to preserve future access even if the original session is revoked. That is why recon-to-persistence often shows both discovery verbs and administrative verbs in the same incident window.

Which API patterns usually signal persistence rather than harmless browsing

Read-only calls by themselves are often consistent with normal troubleshooting, inventory, or automated checks. The concern rises when the activity pattern starts to include changes to entitlements or credentials, especially after a suspicious login, MFA anomaly, impossible travel event, or access key alert. The strongest clue is a transition from what can I see? to what can I change to stay?

In practice, the analyst should separate three buckets: discovery, privilege shaping, and durable foothold creation. Discovery includes calls like listing users, roles, policies, and attached resources. Privilege shaping includes policy edits and trust relationship changes. Durable foothold creation includes new users, new keys, or new credentials that can be used later without relying on the original compromised session.

For AWS-specific attack paths and public incident patterns, TruffleNet BEC Attack, Stolen AWS Credentials and Salt Typhoon US telecoms breach show how credential abuse and later-stage persistence often sit on the same kill chain.

What matters most is whether the actor is touching controls that govern future access. If the actions change policy attachments, trust relationships, or long-lived credentials, you should treat the event as a persistence attempt even if no payload deployment has occurred yet.

What analysts should do once recon becomes persistence

The first decision is containment scope. Do not wait for malware or exfiltration confirmation if the sequence already shows policy modification or credential creation. Contain the session, revoke the affected credentials, and review whether the actor added a backdoor path through IAM, roles, or federated trust.

Next, validate whether the changes are self-serve administrative drift, automation, or malicious persistence. The practical test is whether the actor gained a new durable path that survives the original login state. If yes, the incident has moved beyond reconnaissance, even if the attacker has not yet used the new path.

For incident handling and detection engineering around identity-driven abuse, ITDR guidance is useful for mapping alerts to identity compromise, while CISA's Known Exploited Vulnerabilities Catalog helps you distinguish a cloud-access compromise from a broader intrusion path that may have started elsewhere.

Persistence in AWS is often quiet after the initial change, so logging and configuration review must cover the exact resources that were modified, not just the login event. The most reliable signal is a combination of suspicious read activity, then a control-plane write that increases future access, then follow-on use of that new access path.

Risk and Threat Considerations

The main risk is that reconnaissance gives an attacker enough context to select a low-friction persistence method before defenders react. In AWS, the management plane exposes identity, policy, and trust objects that can be changed quickly, so a short burst of discovery can be followed by access changes that outlive the original compromise.

Failure mechanism: The attacker enumerates IAM and account structure, then uses policy edits, trust changes, or new credentials to create a durable access path that does not depend on the original session.

Impact: You can lose containment even after the visible login is blocked, because the attacker may still retain a valid path back into the environment.

Practitioner Guidance

What to verify: Confirm whether the read activity and the later write activity came from the same principal, source IP, or session chain, and check whether the write changed future access rather than merely observing state. If the answer is yes, treat the event as persistence-oriented until proven otherwise.

Decision rule: If you see discovery followed by credential creation, policy attachment, or trust-policy change, prioritise credential and access-path containment over further triage of the original reconnaissance.

What good looks like: Your detection stack should flag the sequence, not just the single API call, and your responders should be able to show which access path was added, when it was added, and whether it was removed.

Practitioner takeaway: In AWS, persistence often begins as ordinary-looking discovery, so the decisive signal is the first control-plane change that converts visibility into durable access.

Related resources from NHI Mgmt Group

• Why is NHI ownership attribution important for incident response?
• How do attackers turn a supply-chain incident into wider NHI compromise?
• What are the signs that an AWS account has been used for privilege escalation and persistence in EKS?
• What are the signs that AWS Systems Manager is being misused for persistence or credential theft?