What happens when an attacker uses compromised AWS credentials to backdoor security groups and start instances?

How compromised AWS credentials turn into network reach and instance access

Once an attacker has valid AWS credentials, the key question is not just whether they can log in, but what those credentials can change. In this attack path, the compromised principal was used to modify security groups and launch compute, which converted stolen access into a live foothold inside the cloud environment. That is a classic privilege-to-persistence escalation path.

Security groups are especially valuable to an attacker because they control inbound and outbound reach at the network boundary. If the credentials can create or edit rules, the attacker can expose management ports, database ports, or application ports that were previously closed, then use that newly opened path to reach 230M AWS environment compromise style infrastructure abuse. In effect, the credential is no longer just an authentication secret, it becomes a control plane key.

Starting an instance matters because it gives the attacker an asset they can shape, inspect, and potentially access interactively. If the same stolen credentials can attach roles, alter networking, or access user data, the attacker can turn a dormant cloud account compromise into command-line access, data access, or a staging point for later movement. That is why cloud credential compromise often produces faster impact than a simple login theft.

Why backdoored security groups are such an effective persistence mechanism

Backdooring security groups is not only about opening a port once. It creates a durable access path that can survive session expiry, password resets on unrelated systems, or normal user activity. If the attacker adds ingress for common administrative services or broad source ranges, the environment may remain exposed until someone notices the rule change and restores the intended policy.

The mechanism is attractive because it blends into ordinary cloud administration. Security group edits and instance starts can look like routine operations unless teams are actively reviewing change history, source IPs, and unexpected rule drift. That makes the control failure less about a single malicious command and more about weak change visibility across the cloud control plane.

This is also why cloud credential abuse frequently combines network exposure with infrastructure sprawl. One compromised identity can change who can reach the workload, what is running, and which services are exposed to the internet or to adjacent subnets. The attacker does not need to break the service if they can reshape the environment around it.

What the attacker is trying to achieve after the initial compromise

The immediate goal is usually not just access, but reliable access. Opening security groups allows the attacker to bypass normal segmentation and create a path to SSH, RDP, database endpoints, or application management interfaces. Starting an instance provides a controllable place to test access, run commands, and establish a foothold that is easier to revisit than a one-time stolen session.

From there, the compromise can expand into discovery, secret harvesting, and lateral movement across cloud services. If the attacker can reach an EC2 instance, they may look for attached roles, configuration files, environment variables, or access paths into storage and databases. That is why the described sequence is serious: it is not just account misuse, it is the conversion of cloud control privileges into operational control.

For a related cloud-credential abuse pattern, see Codefinger AWS S3 ransomware attack, which shows how compromised AWS credentials can be used for destructive cloud actions once the attacker has control-plane access.

Risk and Threat Considerations

Compromised AWS credentials are dangerous because they let an attacker act as a trusted operator inside the cloud account. If those credentials can modify security groups or launch instances, the attacker can create access paths that look like legitimate administration while materially expanding exposure and persistence.

Failure mechanism: The attacker abuses control-plane permissions to change network reach, then uses the newly exposed path to access running infrastructure or stage additional activity. Because the actions are performed with valid credentials, they can bypass many perimeter controls and appear as ordinary cloud management.

Impact: The result can be instance compromise, exposed services, credential harvesting, data access, and broader cloud foothold establishment. In practice, the blast radius is determined by what the stolen principal can edit, launch, attach, or observe, not by the original login event alone.

Practitioner Guidance

What to verify: Treat any unexpected security group change, instance launch, or attached-role change as a potential compromise indicator. Confirm who made the change, from where, and whether the action matches an approved change ticket or deployment window.

What to prioritise: Prioritise revoking the compromised principal, restoring network rules from a known-good baseline, and checking whether any newly launched instance or newly exposed service has already been accessed. If the attacker could modify ingress, assume the environment may have been reachable long enough for follow-on activity.

Practitioner takeaway: In cloud incidents, the most important question is often not “was the credential stolen?” but “what control-plane actions did the stolen identity allow?”

Related resources from NHI Mgmt Group

• What is the impact of using hard-coded credentials on security?
• How should security teams validate whether an AWS compromised-key quarantine policy actually blocks attacker follow-on activity?
• What happens when an attacker uses a compromised Global Administrator account to extend Azure control?
• What happens when an attacker uses a compromised marketing platform account as a phishing launchpad?