IT PATH
My Path

Cloud and Identity Attack Defence

Detect and defend against modern identity-centric attacks across hybrid and cloud estates.

Certification
CompTIA SecurityX
Recommended study time
6h 30m
Status
Not started

Recommended study time

About 6h 30m in total, measured from the material on this page. At your session length of 45 minutes that is 9 sittings.

  • Read the lesson20 min

    About 2,622 words at a careful technical reading pace.

  • Second pass with notes12 min

    Re-read the harder parts and write your own notes.

  • Recall from memory12 min

    2 written recall questions.

  • Practice decision12 min

    One applied decision with feedback.

  • Teach it back20 min

    Write the topic in your own words.

  • Real-world scenario15 min

    Read the situation and justify your decision in writing.

  • Hands-on practice3h 20m

    Labs, commands and configuration until you can do it unaided.

  • Spaced review1h 40m

    4 short review sessions spread over the following weeks.

Learning objectives

  • Describe token theft, consent abuse, and federation attacks and their signals.
  • Design detections and controls specific to cloud identity abuse.
  • Respond to a cloud identity compromise including token and session revocation.

Start here

About 8 minutes of reading, in 10 short parts.

Modern attackers increasingly skip endpoints and networks entirely, going straight after cloud identities, because a stolen session token or a malicious permission grant can hand over access from anywhere in the world with no malware involved at all. Defending against this requires thinking in terms of identity signals rather than traditional network or endpoint alerts.

Where you meet it: An analyst investigates why mailbox forwarding rules appeared on an executive's account minutes after the password was already reset, and discovers the reset alone did not stop the attacker.

The lesson, part by part

Open one part at a time. Each part stands on its own, so you can stop and come back.

Imagine a hotel room key card system where, once you check in, the card works until checkout regardless of whether you change your name at the front desk. If a thief copies your key card, changing your name later does nothing to stop them opening your door with the copy they already have. A stolen session token works exactly like that copied key card: it keeps working even after you change your password.

A malicious permission grant is like giving a stranger a standing invitation to enter your house to water your plants while you're away, and forgetting you ever agreed to it. Even long after you've forgotten, that stranger can still walk in the front door using the permission you granted, until someone specifically remembers to revoke that exact invitation.

Key ideas

If you remember nothing else from this topic, remember these.

  • Cloud identity is the new perimeter, and compromised credentials or tokens are now a more common initial access path than network exploitation.
  • Excessive IAM permissions and unused roles create a large attack surface even without any software vulnerability present.
  • Cloud logging sources such as CloudTrail and Azure Activity Logs are essential telemetry that many organisations fail to centralise or retain properly.
  • OAuth consent phishing allows an attacker to gain persistent access to a mailbox or files without ever needing the user's password again.
  • Misconfigured storage buckets and overly permissive resource policies remain a leading cause of cloud data exposure.
  • Cloud attacks often chain identity compromise with metadata service abuse to escalate from a single compromised workload to broader account access.

Investigating an AWS metadata service credential theft chain

A worked example, step by step.

A CloudTrail alert fires for an unusual API call pattern from an IAM role normally used only by a single EC2 instance, now originating from an unfamiliar external IP.

  1. 01Pull CloudTrail eventsQuery CloudTrail for eventName=AssumeRole and eventName=GetCallerIdentity for the affected role and find the temporary credentials being used from an IP outside the known VPC ranges.
  2. 02Correlate with the EC2 instanceCheck the instance's application logs and find evidence of a server-side request forgery vulnerability in a public-facing web app that was exploited hours earlier.
  3. 03Confirm the techniqueRecognise the SSRF was used to reach the instance metadata service at 169.254.169.254 to steal the IAM role's temporary credentials, mapping to T1552.005 Cloud Instance Metadata API.
  4. 04Assess blast radiusReview the IAM role's attached policy and find it has overly broad s3:* permissions across all buckets, far beyond what the application actually needs.
  5. 05Check for data accessSearch CloudTrail for GetObject and ListBucket calls made with the stolen credentials and confirm access to a bucket containing customer PII exports.
  6. 06Contain the incidentRevoke the temporary credentials by attaching a deny-all policy to the role, rotate the instance's IAM role, and patch the SSRF vulnerability.
  7. 07Remediate root causeEnforce IMDSv2 (which requires a session token, mitigating simple SSRF-based metadata theft) and scope the IAM role down to only the specific buckets and actions required.
  8. 08Document impactRecord which specific PII records were accessed based on GetObject calls for breach notification assessment.

Outcome: The investigation traces a web application vulnerability through cloud metadata credential theft to actual data access, resulting in credential rotation, IMDSv2 enforcement, and least-privilege IAM remediation.

Cloud and identity attack defense reference

Worth keeping at hand while you work.

T1552.005
Unsecured Credentials: Cloud Instance Metadata API
T1078.004
Valid Accounts: Cloud Accounts
T1550.001
Use Alternate Authentication Material: Application Access Token
IMDSv2
Session-oriented AWS metadata service version mitigating SSRF credential theft
CloudTrail
AWS API call logging service
Azure Activity Log
Azure resource-level operation logging
OAuth consent phishing
Tricking a user into granting a malicious app persistent access via OAuth scopes
Least privilege IAM
Scoping permissions to only what a role or user specifically requires
CSPM
Cloud Security Posture Management, detecting misconfigurations across cloud accounts
SSRF
Server-Side Request Forgery, often used to reach internal metadata endpoints
Conditional access policy
Identity provider rule restricting sign-in by device, location, or risk level
Federated identity
Authentication delegated to an external identity provider such as SSO

Common misunderstandings

What most beginners get wrong here.

  • Cloud security is primarily about network firewall configuration.

    Identity and IAM permissions are now the primary attack surface in cloud environments, often mattering more than network controls.

  • Broad IAM permissions are fine as long as no vulnerability is present.

    Excessive permissions create a large attack surface on their own, since any credential theft or misconfiguration immediately grants excessive access.

  • Stealing a password is required to compromise a cloud account.

    OAuth consent phishing and metadata credential theft allow persistent or temporary access without ever obtaining the user's password.

  • AWS instance metadata service is inherently secure by default.

    IMDSv1 is vulnerable to SSRF-based credential theft; IMDSv2 must be explicitly enforced to require a session token.

  • Cloud logging is automatically comprehensive once a cloud account is created.

    Logging services like CloudTrail must be explicitly enabled, centralised, and retained; many organisations miss key event categories by default.

Exam traps

How the question writers try to catch you out.

  • CySA+ and CASP+ scenarios test recognising SSRF combined with metadata service access as a specific cloud credential theft technique.
  • Expect questions distinguishing OAuth token theft from traditional password compromise as an identity attack vector.
  • Exam items test that least-privilege IAM policy, not network segmentation alone, is the primary mitigation for excessive cloud permissions.
  • Watch for questions requiring you to identify IMDSv2 enforcement as the specific fix for metadata credential theft via SSRF.
  • Questions may test which cloud log source (CloudTrail, Azure Activity Log) is relevant to a specific described cloud provider scenario.

Check yourself

Answer in your head first, then reveal. This is not scored.

  • What ATT&CK technique describes stealing credentials via the cloud instance metadata service?

  • How does IMDSv2 mitigate SSRF-based credential theft?

  • What makes OAuth consent phishing dangerous compared to password phishing?

  • Why is least-privilege IAM important even without a known vulnerability?

  • What cloud log source would you check for AWS API call history?

  • What is CSPM used for?

Quick reference

A condensed summary of the lesson above, for revision.

What It Is

Identity-centric attacks include phishing for session tokens, adversary-in-the-middle proxies that capture authenticated sessions, illicit OAuth consent grants, abuse of federation trust and signing keys, service principal and API key abuse, and privilege escalation through cloud role assignment. Defence relies on phishing-resistant authentication, conditional access, consent governance, key protection, and identity-focused monitoring.

Why It Matters

MFA alone no longer stops credential phishing when the session token itself is stolen. Detection depends on identity telemetry and behavioural signals rather than endpoint alerts.

How It Works

  • Identity providers issue tokens whose lifetime and scope determine attacker persistence.
  • Conditional access evaluates device, location, and risk before and, with continuous evaluation, after issuance.
  • Audit logs record consent grants, role assignments, and sign-in properties.

Where You See It

  • Business email compromise, SaaS data theft, cloud administrative abuse, and supply-chain application compromise.

Key Terms

Token theft
Stealing an issued session token to bypass authentication.
AiTM
Adversary-in-the-middle proxy capturing live authentication.
Consent grant
Permission given to an application to act on a user's behalf.
Service principal
A non-human identity used by an application.
Continuous access evaluation
Near real-time revocation on risk signals.

Examples

  • An attacker with a stolen token can read mail without ever triggering an MFA prompt.
  • A malicious application consent can retain mailbox access even after a password reset.

Common Problems

  • Legacy authentication enabled
  • Unrestricted user consent
  • Over-permissioned service principals
  • Long token lifetimes
  • No identity-focused detections

How It Fails

  • A password reset leaves the attacker's session token and consent intact.
  • An unmonitored service principal grants persistent access with no user to disable.
  • Legacy authentication protocols bypass conditional access entirely.

How to Troubleshoot

  1. Review sign-in logs for token issuance, device, and location anomalies.
  2. Enumerate and revoke application consents and refresh tokens during response.
  3. Audit role assignments and service principal credentials for unexpected additions.

Practical Knowledge

  • Restrict user consent to verified publishers with an admin approval workflow.
  • Include token and consent revocation as standard steps in identity incident playbooks.

Exam Coverage

  • Cloud identity attack techniques
  • Conditional access and phishing-resistant authentication
  • Identity incident response

Interview Questions

  • Why is a password reset insufficient after token theft?
  • How would you detect malicious OAuth consent?

Watch and read

Verified official and reputable sources for this topic. Links open in a new tab.

Video training

  • Professor Messer video channel — general CompTIA training (no dedicated CompTIA SecurityX course)

    Professor Messer

    Video
    Free
    Watch

Lesson notes and bookmark

Notes and bookmarks for this lesson, saved with everything else you have marked.

No notes on this item yet.

Learning progress

0% across six evidence areas. Reading alone does not change progress.

Understanding0%
Recall0%
Application0%
Practical ability0%
Troubleshooting0%
Retention0%

Prerequisites

Next steps

  1. 01List every application with broad delegated permissions in your tenant.
  2. 02Write the exact revocation steps for a suspected token theft.