4.2 Lab: Credential Incident Desk
Lab: Credential Incident Desk
Applied analysis · 3 credential incidents · 18 points · 35–45 min
You are a tier-1 analyst on the overnight security operations centre shift at Aceshack. Three tickets against the sign-in system have landed within the hour. For each case you review the evidence, write your analysis, and submit it for scoring — the expected analysis appears only after you submit, so write first.
Your task per case: (1) name the attack and the nearest attack it is not, (2) cite the evidence in the record that proves it, (3) recommend one control that would have stopped it and one that would not have. Each of the nine boxes is worth 2 points: 2 for a response that makes both required claims, 1 for a response that makes one. 18 points total.
Case 1: The One-Try Wave
Reporter: Portal monitoring (automated escalation)
Description: Between 01:05 and 01:22 the public sign-in portal recorded 5,600 failed sign-ins. Nine sign-ins succeeded. Account lockout is configured at five failed attempts and no account locked. Aceshack requires a 14-character minimum and 3-of-4 complexity, and all nine of the passwords that worked met both rules. All nine account owners, when asked, confirmed they had used the same password on a retail site that disclosed a data leak last year.
Portal telemetry:
signin.log — aggregated 01:05–01:22 distinct usernames attempted: 5,412 attempts per username: 1 (maximum observed: 2) distinct source addresses: 1,840 (residential ranges) successful sign-ins: 9 accounts locked out: 0 passwords per username: 1 — each already present in a public leak corpus
No account received a second guess. The nine that opened, opened on the first try.
1. Name the attack — and name the nearest attack this is not:
2. Cite the evidence in the log that proves it:
3. One control that stops it — and one that would not have:
Expected analysis:
(1) Attack: Credential stuffing. The attacker is replaying username and password pairs stolen from a breach at another company, so what is being exploited is password reuse, not a weak password. It is not brute force, which throws many passwords at one account, and it is not password spraying, which throws one common password at many accounts. Here every account received a different password — its own.
(2) Evidence: Every username was tried exactly once, so the run stayed under the lockout threshold and no account locked. Each password submitted was already a valid password somewhere, which is why nine of them opened on the first try; guessing does not produce nine hits in 5,412 single attempts. And all nine met the 14-character floor and the complexity rule, so length and complexity did not fail here — reuse did.
(3) Control: Require a second factor on the portal, and screen every new or changed password against a list of passwords known to be breached. What would not help: lowering the lockout threshold buys nothing, because the attacker never made a second attempt at any account, and raising the length floor buys nothing either, because the stolen passwords already satisfied it.
Scoring: 2 points per box for a response that makes both required claims, 1 point for one claim, 0 for a response under 15 characters. Case 1 is worth 6 points.
Case 2: The Decommissioned Backup
Reporter: Threat intelligence vendor (external notification)
Description: A backup image taken from an Aceshack server that was decommissioned in 2019 has been found for sale on a criminal forum. The image contains the credential store. Two tables are inside it — a retired table that was never migrated, and a copy of the table the current portal uses. Sample rows:
legacy_users (retired 2019, 3,540 rows, never migrated) a.okafor 5f4dcc3b5aa765d61d8327deb882cf99 j.mensah 5f4dcc3b5aa765d61d8327deb882cf99 t.ruiz e10adc3949ba59abbe56e057f20f883e m.iqbal 5f4dcc3b5aa765d61d8327deb882cf99 portal_users (current, 4,102 rows) a.okafor $2b$12$Kx9pQ7rT… salt: 9f3c1e04b7 j.mensah $2b$12$Wq2mLd8Z… salt: 41b8da62c5 t.ruiz $2b$12$Hn5vXe1R… salt: c07e93f1a8
Thirty-six hours after the image was posted, a researcher monitoring the forum reported that 3,100 of the 3,540 legacy passwords had been recovered. Not one portal_users password has been recovered. Aceshack sign-in logs for the same 36 hours show no unusual activity at all.
1. Name the attack — and name the nearest attack this is not:
2. Cite the evidence that explains why one table fell and the other did not:
3. One control that stops it — and one that would not have:
Expected analysis:
(1) Attack: Offline cracking of a stolen hash file — dictionary and rainbow-table recovery run on the attacker’s own hardware. It is not an online guessing attack: nothing is submitted to Aceshack at all, which is exactly why the sign-in logs for those 36 hours are clean.
(2) Evidence: Three legacy rows carry an identical hash string. That can only happen when the same password is hashed with no per-user salt, so one precomputed table cracks the whole legacy file in a single pass. The current table stores a distinct salt on every row and uses a deliberately slow algorithm, so each guess has to be recomputed for each user — which is why 3,100 legacy passwords fell in 36 hours and zero current ones did.
(3) Control: Rehash every surviving credential with a unique per-user random salt and a slow key-derivation function, and force a reset on all 3,540 legacy accounts. What would not help: account lockout does nothing here, and neither does rate limiting or a higher minimum length going forward — every one of those governs attempts made against the portal, and the attacker is guessing against a file he already owns. Note also that the salt does not have to be kept secret. It has to be unique.
Scoring: 2 points per box for a response that makes both required claims, 1 point for one claim, 0 for a response under 15 characters. Case 2 is worth 6 points.
Case 3: The 2 A.M. Approvals
Reporter: Nadia Osei, accounts payable
Description: “At 02:14 someone signed in as me and changed a supplier’s payment details. I was asleep. My phone had been buzzing — there is a wall of sign-in approval requests on it from just after two. I tapped Approve on one of them so it would stop, and went back to sleep. I never entered my password anywhere.”
Authentication log and helpdesk record for the account:
auth.log — user n.osei
02:03:11 approval challenge sent -> registered phone denied
02:03:44 approval challenge sent -> registered phone denied
... 24 further challenges, all denied ...
02:12:06 approval challenge sent -> registered phone APPROVED
02:14:52 session established -> supplier payment record modified
helpdesk.log — previous day
15:40:22 inbound call, caller states she is locked out
15:44:07 technician verified caller: employee ID number + mother’s maiden name
15:45:19 password reset issued verbally over the phone
1. Name both failures in the chain — the two are different attacks:
2. Cite the evidence for each, including what the technician actually checked:
3. One control that stops it — and one that would not have:
Expected analysis:
(1) Attack: Two failures chained, and both have to be named. First an account-recovery bypass: the attacker social-engineered the service desk into issuing a password reset over the phone. Then MFA fatigue, also called push bombing — flooding the enrolled device with approval prompts until the owner taps Approve to make them stop. Nothing was guessed and nothing was cracked; every credential was handed over.
(2) Evidence: 27 challenges inside nine minutes ending in a single approval is the fatigue signature — a genuine sign-in generates one prompt, not 27, and the denials show the owner was refusing until she stopped reading them. On the recovery side, both items the technician checked — the employee ID number and the maiden name — are things the user knows. The reset was therefore verified with a second knowledge factor, which is the same category of factor as a password, not a second factor at all.
(3) Control: Switch push approval to number matching, so approving requires reading a number off the sign-in screen — which the attacker can see and the sleeping user cannot — and rate limit how many challenges one account can receive per minute. On the recovery path, require a factor of a different type: a code to the enrolled device, or an in-person check at the drop-in desk. What would not help: adding a third security question to the helpdesk script, because three things you know are still one factor.
Scoring: 2 points per box for a response that makes both required claims, 1 point for one claim, 0 for a response under 15 characters. Case 3 is worth 6 points.
The Device Security Analysis free-response task asks you to do on paper what this lab just asked on screen: read a record, name the mechanism, and justify a control with the evidence in front of you. Notice what carried across all three cases — the control that is correct depends entirely on where the guessing happens. Account lockout is the right answer against an online attack and worthless against an offline one; a longer password helps against cracking and does nothing against reuse or against a user who approves a prompt. Never recommend a control without naming the attack it is answering.
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]