Responding to leaked credentials and privilege escalation

Why this matters

CompTIA puts security incidents in the troubleshooting domain and names leaked credentials and privilege escalation specifically. That placement is deliberate: it is framed as something you detect and resolve, not as a policy topic.

It is also the most realistic cloud incident there is. The earlier objectives explained why credentials leak — a key in a repository, a key in an image, a key in user data, a phished session — and this lesson is what to do when one has.

The ordering principle is the one thing to take away: contain first, investigate second. Every hour spent understanding the attack before revoking access is an hour the attacker still has it.

This lesson stays defensive throughout. It describes what the evidence looks like and how to shut an intrusion down, which is what the objective asks for.

The lesson

Recognising the signals: impossible travel, new regions, unusual API calls, new keys

Detection comes from the audit trail (objective 3.3), and the signals are consistent enough to list.

Identity signals:

• Impossible travel — sign-ins from two locations too far apart for the time between them.
• Sign-in from an unfamiliar country, network or device, particularly from hosting-provider address space, which legitimate staff rarely use.
• A spike in failed authentications, then a success — credential stuffing that worked.
• Repeated MFA prompts, which is the fatigue attack from objective 4.2.
• Use of a credential that has been dormant for months.

Activity signals, which are the higher-confidence ones:

• Reconnaissance calls — a burst of list and describe operations across many services in a short period. Legitimate use is usually narrow and repetitive; enumeration is broad and shallow, and it is one of the clearest early indicators there is.
• Resource creation in an unused region. Attackers use regions nobody watches, which is why the region-deny policy from objective 4.2 is a detection control as well as a preventive one.
• New identities, keys or roles created, especially by an identity that does not normally do that. Attackers establish persistence early.
• Changes to logging — a trail disabled, a log destination deleted, a retention period shortened. This is a very high-confidence signal, and it is why immutable logs and an explicit deny on disabling them matter.
• Security controls weakened — a security group opened, MFA removed, a policy broadened.
• Unusual data access, particularly large reads or bulk exports from storage, or snapshots being shared outside the account.
• A large number of expensive instances launched, which is usually cryptocurrency mining and is often detected first by the cost anomaly detection from objective 1.8.

External signals matter too and are a common way organisations learn: provider abuse notifications, automated alerts that a credential has been found in a public repository, and reports from third parties.

Containment first -- revoke, rotate, disable -- before investigation

The sequence, and getting the order right is the examinable part.

1. Revoke the credential's access. For an access key, deactivate it — do not delete it yet, because deleting destroys evidence and the identifier you need for the investigation. For a user, disable sign-in. For a role, attach an explicit deny or remove the trust policy.
2. Invalidate active sessions. This is the step people miss, and it matters because revoking a key does not end sessions already established with short-lived credentials derived from it. Most platforms offer a way to invalidate all existing sessions for an identity or to deny requests issued before a timestamp. Without this the attacker keeps working for hours with a credential you believe you revoked.
3. Rotate anything that credential could read. Assume every secret it had access to is compromised — database passwords, API keys, tokens, signing keys. This is usually a much longer list than the credential itself and is the part most often under-scoped.
4. Isolate affected resources rather than terminating them. Move a compromised instance to a restrictive security group with no egress, detach it from load balancers and scaling groups so it is not replaced, and leave it running. Terminating destroys memory-resident evidence, and in an autoscaling group termination simply triggers a clean replacement while the root cause remains.
5. Preserve evidence: snapshot volumes, capture memory if you have the capability, and export the relevant logs before any retention window can expire.

Then, and only then, investigate.

Two judgement points worth carrying. Containment is disruptive and that is acceptable — the cost of a brief outage is almost always lower than the cost of continued unauthorised access, and this trade should be agreed in advance so nobody is negotiating it during an incident. And do not tip off the attacker prematurely where the response is being coordinated — though in practice, for a leaked credential, immediate revocation is nearly always right.

Working out what the credential could reach, and what it actually did

Two separate questions, and both are needed.

What could it reach? The blast radius, derived from the identity's permissions. Enumerate its policies, the roles it could assume, the resource-based policies granting it access, and any cross-account trust. Platform tooling can generate this analysis. This defines the worst case and therefore the scope of rotation and notification — and it is also where organisations discover that an identity they thought was narrow was not, which is objective 4.2's access review arriving too late.

What did it actually do? From the audit log, every API call made by that identity in the period. Work outward from the first suspicious event:

• Establish when access began, which is usually earlier than the alert.
• List every action taken, and separate reads from writes. Reads mean potential data exposure; writes mean changes to undo.
• Identify anything created — instances, keys, users, roles, snapshots, policy changes — because those are persistence and they survive revoking the original credential.
• Identify data accessed, which determines notification obligations under the regimes in objective 4.4.
• Check whether the credential was used to obtain other credentials, which extends the incident.

The logs are the evidence, which is why the controls that protect them matter: centralised, immutable, in a separate account, with retention long enough that an incident discovered weeks later is still investigable. An attacker's first move against a well-run estate is frequently the logs, and an estate where that succeeds cannot answer either question above.

Privilege escalation paths in cloud identity, especially role assumption and policy edits

Cloud privilege escalation rarely involves an exploit. It involves using permissions that were granted, in combinations nobody considered. Knowing the shapes helps you both detect and prevent them.

The common paths:

• Permission to modify policies. An identity that can edit IAM policies can grant itself anything. This is the most direct path and the most commonly over-granted permission.
• Permission to assume a more privileged role, where the trust policy is broader than intended.
• Permission to pass a role to a resource. Create an instance or a function with an administrative role attached, then use it. This is why the pass-role permission exists separately (objective 6.1) and why it must be scoped.
• Permission to create access keys for another user, including a privileged one.
• Permission to update a function's code, where that function runs with a privileged role.
• Permission to modify infrastructure code or the pipeline that deploys with privileged credentials (objective 5.3) — privilege escalation by pull request.
• Access to the metadata service from a compromised workload or through server-side request forgery (objective 2.4), yielding the instance's role credentials.

The preventive controls are all from domain 4, and this is where they pay off: permission boundaries so an identity cannot grant beyond a ceiling; organisation policies denying absolutely; scoped pass-role; least privilege on identity-management actions specifically; hardened metadata service; and monitoring identity changes as high-priority events.

Tooling that analyses effective permissions and reports escalation paths is worth running proactively — it finds these combinations before an attacker does, and the findings are usually surprising.

Recovery and the control change that stops the same route being used twice

Recovery is more than removing access.

Remove persistence. Everything the attacker created: identities, keys, roles, trust relationships, functions, scheduled tasks, instances, shared snapshots and images, and any modified policy. This must be driven by the enumeration above rather than by looking around, because persistence is placed where it will not be noticed.

Restore integrity. For compromised compute, rebuild rather than clean (objective 4.1): a fresh instance from a known-good image, because you cannot prove a compromised system is clean. Infrastructure as code makes this straightforward, which is a genuine security benefit of everything in domain 2. For data, restore from a backup taken before the compromise, which is why retention long enough to predate the incident matters (objective 3.2).

Close the entry route. The specific question: how did the credential leak? A repository commit, an image layer, user data, a phish, an over-permissive role, a vulnerable application? Each has a specific fix — secret scanning and push protection, run-time secret injection, an instance role instead of a key, phishing-resistant MFA, a narrowed policy, a patch.

Then make the class of failure harder, which is what distinguishes a handled incident from a learning one:

• Eliminate the credential type that leaked. If a long-lived key leaked, replace long-lived keys with role-based short-lived credentials everywhere, and consider denying key creation outright.
• Add the detection that would have caught it sooner, and measure the gap between the attacker's first action and your first alert.
• Test the response. An incident is the best time to discover a runbook is wrong, and the worst time.

Run a blameless post-incident review. Credential leaks are usually a process and tooling failure rather than an individual one, and a review that finds someone to blame reliably produces an organisation where the next incident is reported later.

Finally, check the notification obligations (objective 4.4). If personal or regulated data was accessed, there are legal duties with short deadlines, and determining whether they apply is part of the investigation rather than an afterthought.

What to take into the exam

• Contain first, investigate second. Revoke, invalidate active sessions (revoking a key does not end sessions), rotate everything it could read, isolate rather than terminate, preserve evidence.
• Terminating a compromised instance destroys evidence — and in a scaling group it is simply replaced.
• Answer two questions: what it could reach (permissions) and what it did (audit log).
• Highest-confidence signals: broad enumeration calls, resources in unused regions, new keys/roles/users, and logging being disabled.
• Escalation paths are granted permissions in unexpected combinations — policy editing, role assumption, pass-role, key creation for others, function code updates, pipeline access, and the metadata service.
• Rebuild rather than clean a compromised host; restore data from before the compromise.
• Close the specific route, then eliminate the class — replace long-lived keys with short-lived role credentials. Blameless review; check notification obligations.