Certified Cloud Security Analyst: The contractor with a valid session token

The contractor with a valid session token

Northwind Logistics federates 4,200 employees and 900 contractors from Okta into AWS IAM Identity Center and Microsoft 365. Okta Verify push is the second factor for about 70% of users; the remainder still use SMS. Hiring managers create contractor accounts through SCIM with a 12-month term, and nobody reviews them until term end. AWS holds 1,200 IAM users with long-lived access keys used by scripts, plus 40 roles trusted by GitHub Actions. Last month a contractor's laptop was infected. The attacker stole the Okta session cookie, replayed it through a residential proxy in the same city within 40 minutes, and created a new IAM user with AdministratorAccess - recorded by CloudTrail as a CreateUser from an unfamiliar ASN. Impossible-travel alerting never fired. Before discovery, the attacker listed and downloaded objects from two S3 buckets containing 3.1 TB of rate cards and customer contracts.

1. Why did the existing MFA and anomaly detection fail, and which specific controls address session-token theft rather than credential theft?

Read the worked answer

Why it failed. Push and SMS MFA authenticate a login event; they do nothing for a request that already carries a valid session cookie. The attacker never re-authenticated, so no factor was challenged. Impossible-travel is a geographic heuristic, and a residential proxy in the same city defeats it by construction - you cannot detect token replay by asking "is this location plausible?"

Controls aimed at the session.

Phishing-resistant, origin-bound authenticators: FIDO2/passkeys or Okta FastPass, which bind the credential to the relying party origin and are not exportable, unlike a cookie.
Device-bound conditional access: require a managed, compliant device posture for IAM Identity Center and for any data-plane access to sensitive buckets. A stolen cookie replayed from an unmanaged machine fails the device signal even though the user is authenticated.
Shorter sessions and step-up: reduce Identity Center session duration (default 8 hours is generous for admin roles), disable long-lived "remember this device," and force re-authentication for sensitive operations such as IAM principal creation.
Binding and continuous evaluation: token protection where the platform supports it, and continuous access evaluation so revocation is immediate rather than at token expiry.

Detection. Replace geography with behaviour: first-seen ASN, new device fingerprint, console session calling an API never used by that user, or a user creating IAM principals at all. Baselines over CloudTrail, not travel distance.

Also retire SMS deliberately - it is a restricted authenticator under current NIST guidance, not merely a weaker one.

2. You must retire 1,200 long-lived IAM user access keys. Sequence the work and address the legitimate blockers you will meet.

Read the worked answer

Do not start with rotation. Rotating a long-lived key recreates the same failure mode with a new value. The target state is no static keys.

Discover and classify (weeks 1–3). Pull the IAM credential report, IAM Access Analyzer findings, and CloudTrail last-used data for every key. Group into: human accounts (should be federated - deleting the key forces the right behaviour), CI/CD workloads, third-party integrations, and genuinely legacy on-premises scripts. Assign an owner per key; unowned keys are deleted after a grace period, not left indefinitely.

Prevent growth (week 2). An SCP denying iam:CreateAccessKey for all principals except a break-glass role, so the population cannot regrow while you drain it.

Migrate by pattern (weeks 3–12).

CI/CD: GitHub Actions OIDC federation to roles scoped by repository, branch and environment - this also removes the credential that caused this incident.
Third parties: cross-account roles with external IDs and source conditions; use IAM Roles Anywhere for workloads that cannot assume a role, rather than issuing keys.
Humans: Identity Center permission sets only; delete keys on a published date.

Blockers, handled honestly. Vendors that "only support access keys" need a contractual answer or a compensating control (IP-restricted, rotated, monitored). On-premises cron jobs need a migration plan with a dated cutover, not a permanent exemption. Expect one team to rediscover a keyless path only when the old key stops working - so instrument last-used alerts 30 days before deletion.

Measure the percentage of workloads operating without long-lived credentials, not the number of keys rotated.

3. 3.1 TB left the environment before anyone noticed. What data-layer controls would have limited blast radius, and what are the first 72 hours?

Read the worked answer

Blast-radius controls that were missing.

Bucket-level least privilege: no broad s3:GetObject on shared prefixes; per-consumer S3 Access Points with their own policies and, where appropriate, VPC endpoint restrictions so only known networks can read.
Key-policy boundary: customer-managed KMS keys whose grants permit decryption only to specific workload roles. An AdministratorAccess user with a stolen session still cannot read ciphertext if the key policy does not permit it - this is the strongest single limit available.
Guardrails: an SCP denying s3:GetObject on the contract-data buckets except for approved role ARNs, and a permission boundary preventing newly created principals from exceeding a defined ceiling. The attacker's first action was CreateUser with AdministratorAccess; that should have been impossible from a contractor session.
Detection: Macie for classification, S3 data events with an alert on volume anomalies (for example, more than 5 GB per hour from one principal), and alerts on first-ever principal creation.

First 72 hours. Contain identity before hosts: revoke sessions, disable the created IAM user and its keys, quarantine the contractor account. Preserve CloudTrail, S3 server access logs and VPC flow logs into the locked log-archive account. Scope the read: which prefixes, how many objects, over what window. Then involve counsel early - notification thresholds differ (contractual, state breach law, GDPR if EU residents appear in the contracts), and security should not be deciding legal thresholds alone. Finally, treat the data as disclosed: rotate any secrets inside those documents and notify the commercial owners, because rate cards and customer contracts are competitively sensitive even where no personal data is involved.