What happens when an attacker gets root access in AWS and starts spinning up infrastructure?

How Root Access Changes the Attack From Access to Expansion

Root in AWS usually means the attacker can move beyond simple misuse and start creating durable infrastructure that supports persistence, collection, and command-and-control. The important shift is not just privilege level, it is speed: once the attacker can provision resources, the incident becomes a race between their automation and your detection and containment.

That expansion path often includes new compute, new network reachability, and changes that make the environment harder to inspect. In practice, the compromise can stop being a single bad credential and become a rapidly growing cloud footprint that demands both security response and cloud operations response.

For a broader view of how real compromises progress once credentials are abused, The 52 NHI Breaches Report is useful because it shows how quickly a single identity compromise can broaden into lateral movement and infrastructure abuse.

What Infrastructure Abusers Actually Build First

Attackers who gain root access tend to create the simplest assets that improve reach and control. That can mean spinning up EC2 instances for staging, opening security groups for remote access, creating or modifying routes and peering relationships, and planting additional credentials or keys so they are not dependent on the original entry point.

The goal is usually not novelty, it is resilience. A new instance can host tools, relay traffic, or serve as a pivot point. Relaxed network controls can expose management ports or data paths. Once those changes exist, the attacker has reduced the defender’s advantage because the environment now contains attacker-created infrastructure that looks operational unless you are monitoring for it directly.

Cloud credential abuse at scale is not hypothetical. The 230M AWS environment compromise case illustrates how exposed cloud secrets can be turned into large-scale environment takeover and infrastructure expansion.

If the attacker is using stolen cloud credentials rather than application flaws, the defensive problem is usually account control and change visibility, not code hardening. In other words, the relevant question becomes which API actions were possible from that root session and whether those actions were logged, alerted on, and reversible.

Why Cost, Exposure, and Response Scope Blow Up So Fast

Infrastructure creation changes both financial impact and exposure surface. Every new instance, snapshot, security group rule, NAT path, or exposed service can increase spend, widen the reachable network, and create more places where sensitive data or administrative access can be touched. Even if the attacker’s first move is limited, cloud elasticity makes the blast radius grow faster than many response teams expect.

That is why incident response in AWS has to treat resource creation as a security event, not just an operations event. Once infrastructure starts appearing under attacker control, the responder has to consider shutdown sequencing, snapshot preservation, credential rotation, log retention, and whether the attacker has created secondary access paths that survive the original credential being revoked.

MITRE ATT&CK Enterprise Matrix is useful for mapping the follow-on behaviour, especially credential access, persistence, privilege escalation, and lateral movement after the initial cloud breach.

For cloud governance and control mapping, CSA Cloud Controls Matrix helps frame the IAM, infrastructure, and logging controls that matter once an attacker is operating inside the account.

Risk and Threat Considerations

When an attacker can provision infrastructure in AWS, the main risk is that the compromise becomes self-expanding. New compute, new routes, and new permissions can outpace manual review, while the attacker uses cloud-native controls to blend malicious activity into ordinary administration.

Failure mechanism: The attacker abuses high privilege to create resources, alter network reachability, and establish alternate access paths before defenders revoke the original access.

Impact: Costs rise, detection becomes harder, data exposure can widen, and containment may require dismantling attacker-built infrastructure rather than only rotating a credential.

Practitioner Guidance

What to prioritise: Treat unexpected resource creation, security-group changes, and route or peering edits as containment triggers, not routine drift. If the attacker can still authenticate, assume any delay increases blast radius.

What to verify: Confirm which identities or sessions created the resources, whether there are attached roles or keys you have not yet found, and whether the attacker introduced a second access path that survives root password reset or key rotation.

Practitioner takeaway: The hard part is not just removing the original access, it is finding and removing every cloud-native foothold the attacker created while the account was still trusted.

Related resources from NHI Mgmt Group

• What happens when an attacker gets root access through a compromised SSH key?
• What happens when an attacker gains admin access in EKS and starts listing secrets?
• What happens if an attacker gets into a public MLOps UI without deeper system access?
• What happens after an attacker gets initial access through a drive-by download?