4.3 Lab: Authentication Triage Desk
Lab: Authentication Triage Desk
Applied analysis · 3 IAM incident cases · Simulated IAM team shift · 35–45 min
You are the tier-1 analyst on an Identity and Access Management (IAM) team. Three tickets have come in this morning. For each case you will: (1) identify the attack, (2) name the access-control or authentication weakness that enabled it, and (3) recommend one short-term and one long-term fix.
Commit your answer BEFORE clicking Reveal. That is the point of the lab.
Case 1: The 2 a.m. Finance Transfer
Reporter: Controller, Finance
Description: A $340,000 wire transfer was initiated at 2:14 a.m. local time from the corporate banking portal. It used the credentials of Jessica M., a finance staff accountant. Jessica says she was asleep and did not initiate the transfer.
Login telemetry:
Login event: Finance Banking Portal Time: 02:14:03 local User: [email protected] Source IP: 193.x.x.x (geolocation: Bulgaria) Device: Chrome on Windows 11 (NOT a managed endpoint) MFA: Approved via SMS code Jessica's phone number was ported to a new SIM 4 hours earlier.
Jessica confirms she lost signal on her phone around 10 p.m. but assumed it was carrier trouble.
1. Attack name:
2. Root-cause authentication weakness:
3. Short-term + long-term fixes:
(1) Attack: SIM-swap attack. The attacker socially engineered Jessica’s mobile carrier into porting her number to an attacker-controlled SIM, then used her already-compromised password + the intercepted SMS code to authenticate.
(2) Root cause: SMS-based MFA for a high-value financial function. SMS relies on the carrier’s (non-security) fraud controls, which are a weak single point of failure. A secondary gap: no device-posture check (the login came from an unmanaged device from an unusual geo with no extra friction).
(3) Fixes: Short-term: reverse the wire (coordinate with bank’s fraud team), force-reset Jessica’s password, invalidate all sessions, contact carrier to confirm the port is reversed and add a port-out PIN. Long-term: replace SMS-MFA with an authenticator app or a FIDO2 hardware key for all finance staff, add conditional-access rules that require a managed device + step-up approval for any transfer over $50K.
Scoring rubric: 1 pt for identifying SIM swap, 1 pt for naming SMS-MFA as the weakness, 1 pt for any two reasonable fixes. 2+/3 = passing.
Case 2: The Vacation Policy Approval
Reporter: Director of HR
Description: The company vacation-carryover policy was silently changed in the HR system over the weekend to increase maximum carryover from 40 hours to 400 hours. The change was submitted, reviewed, and approved by a single user: “hradmin_service.”
Account audit on hradmin_service:
Account: hradmin_service
Type: Service account (no human owner)
Created: 2018
Password: Not rotated since creation (2,100+ days)
Used by: HR automation scripts (documented)
HR weekend on-call (undocumented, per interview)
Privileges: HR Administrator + Policy Approver
MFA: Exempt (service account)
1. Name the two security principles being violated:
2. Why does this make forensic attribution hard:
3. Short-term + long-term fixes:
(1) Principles violated: Separation of duties (one account had both “submit policy change” AND “approve policy change” — no second-person check) and principle of least privilege (a service account held broad HR-admin + policy-approver rights it did not need; password never rotated; MFA exempt).
(2) Why attribution is hard: A shared service account with no individual owner and undocumented human use means the log only shows “hradmin_service did this” — not WHICH human. Six people could have logged in with the same credentials, and a stolen password would look identical to legitimate on-call use.
(3) Fixes: Short-term: revert the policy change, rotate the hradmin_service password, audit every action the account took in the last 14 days, and require MFA even for the service account (via certificate or workload identity). Long-term: split the account into two (one automation-only with minimal rights, one human privileged account per on-call engineer), split submitter and approver into different roles, and require named human accounts for every policy change.
Scoring rubric: Naming BOTH separation of duties and least privilege earns full (1). Identifying the shared-account attribution gap earns (2). Short+long-term fixes touching at least account-splitting, MFA, and role split earn (3). 2+/3 = passing.
Case 3: The SSO Session Explosion
Reporter: SIEM (automated)
Description: Over a 90-minute window, 14 different employees generated “impossible travel” alerts in the SSO provider. Each employee had a session established from the corporate office (approved) and, within the same hour, a new authenticated session established from a South Asian IP address — without any re-prompt for MFA.
Investigation notes:
Common factor across all 14 users:
- All attended a “virtual benefits training” on Tuesday
- The training link was: hxxps://benefits-portal[.]acmecorpenroll[.]info
- The REAL benefits portal: https://benefits.acmecorp.com
- The training link proxied the login to the real SSO and
captured the resulting SAML session tokens.
- SSO sessions have a 24-hour TTL with no re-auth requirement.
1. Attack name:
2. Why did MFA fail to stop this:
3. Short-term + long-term fixes:
(1) Attack: Real-time phishing / adversary-in-the-middle (AITM) with SSO session-token theft. The fake “benefits portal” acted as a transparent proxy: users entered their password AND approved MFA on the real SSO provider, but the attacker harvested the resulting session token. The attacker then replayed the SAML token from their own infrastructure without needing the password or MFA again.
(2) Why MFA failed: MFA authenticated the USER correctly — the user really did enter their password and approve the push. The attack stole the SESSION, not the credentials. This is the limit of any MFA that is not cryptographically origin-bound. FIDO2 / WebAuthn / passkeys would have refused to complete the flow because the request came from a different origin than the legitimate site.
(3) Fixes: Short-term: invalidate all active sessions for the 14 users, force password reset + re-enroll MFA, block
*.acmecorpenroll.info at the DNS layer, search SIEM for the same pattern across the rest of the workforce. Long-term: roll out phishing-resistant MFA (FIDO2 hardware keys or passkeys) for privileged users first, enforce short session TTLs with continuous re-evaluation, add email-gateway rules that flag lookalike domains, and train staff to open company portals from bookmarks rather than emailed links.Scoring rubric: Identifying AITM / real-time phishing proxy earns full (1). Explaining that the attacker stole the session token AFTER successful MFA (not the credentials themselves) earns (2). Naming phishing-resistant MFA + short session TTL + DNS block earns (3). 2+/3 = passing.
All three cases share the same analytical structure: identify the attack, locate the single authentication or authorization weakness that made it possible, and recommend a layered fix. This “attack → weakness → layered fix” chain is the backbone of AP Cyber scenario FRQ-style questions. Practicing it in writing — with full sentences — is the rehearsal you want.
Get in Touch
Whether you're a student, parent, or teacher — I'd love to hear from you.
Just want free AP CS resources?
Enter your email below and check the subscribe box — no message needed. Students get daily practice questions and study tips. Teachers get curriculum resources and teaching strategies.
Message Sent!
Thanks for reaching out. I'll get back to you within 24 hours.
Prefer email? Reach me directly at [email protected]