Investigate Cora's account by pivoting on IDs and build a timeline

Setup

1. Press Start on this page.

2. Open an incident record in your notes with four parts: a timeline (time, source, actor, subject, operation, outcome, request ID), a facts column and a hypotheses column kept apart, responder actions, and the four questions from the lesson.

3. Pretend the alert you wrote in the Detecting identity attacks lab has just arrived: "Cora's account added an authenticator app minutes after a sign-in."

Walkthrough

1. In Audit, source Protocol activity, open Cora's account.security event with method_enrolled from the detection lab. Copy its time, request ID and subject ID (Cora's user ID) into the incident record.

Why it matters: investigations pivot from one known value. The subject ID is stable even if Cora's email changes, so it is the value to search on.

2. Pivot on Cora's ID. In Audit, source User directory, search for her user ID. Every management action that affected her appears: the password you set, the methods reset, the email change and its reversal. Open one and note its actor.

Why it matters: the lesson's responder actions appear in the same records as everything else. Writing down which events were made by administrators, and why, is what keeps them apart from the subject's own actions later.

3. Back in Protocol activity, page through the recent events and list every one whose subject is Cora: sign-ins, second steps, method changes, token requests by lab-printer-app. Put them in time order in the timeline.

Why it matters: a timeline answers how, what and when. Notice that the protocol source filters only by outcome, so you scan by subject yourself; the directory source can search by ID.

4. Mark each line as Cora (actor is her account), administrator (actor is you or Ben), or client (actor is an OAuth client). Then mark where the records cannot tell two sessions on Cora's account apart.

Why it matters: every action by Cora's account names the same actor. The lesson's investigator separated the owner from the attacker by session, network and device, which your records do not carry. Write that down as a limit, not a conclusion.

5. Follow the trail to other accounts. Pivot on lab-printer-app: which other users have oauth.authorize events with code_issued for it? Pivot on the time window of the failed sign-ins: which other accounts had refusals then?

Why it matters: an attacker who reached one account rarely stops there. Each value in the timeline is a thread to another account, and the scope you record is the current scope, not a final answer.

6. For any failure in the timeline, open Logs, source Protocol summaries, and find the summary for that operation and reason on that day, with its first and latest request ID samples.

Why it matters: Audit says who and what; Logs say how requests were handled and how many. Together they explain a failure that one record alone cannot.

7. Answer the four questions for Cora in the incident record: how did access begin, what changed, what access remains, and who else is affected. Mark each answer as fact or hypothesis.

Why it matters: keeping facts and hypotheses apart stops an early guess quietly becoming the conclusion.

8. Preserve the evidence: copy every record in the timeline (fields and request IDs, no secrets) into the incident record before anything is cleaned up.

Why it matters: cleanup can destroy what it removes, and records age out on their own. Capturing them first takes minutes.

Break it

1. Open Collection and retention at the bottom of the Audit page and read the retention period. Work out the date when the oldest record in your timeline will leave the history. Any investigation still open after that date loses it, which is why preservation comes before cleanup.

Check your work

• Check my progress confirms the starting event, the directory search, a responder action's details and the Logs read.

• Your timeline cites real request IDs, labels every line as owner, administrator or client, and answers the four questions.

Cleanup

• None. Keep the incident record; the Containing and recovering lab continues it.

Missing infrastructure

• G41: there is no export or legal hold for a filtered set of records, so copying them by hand is the only preservation. Once it exists, the lab will export the timeline and place a hold that keeps it past the retention period.

• G37: records carry no session ID, network or device, so two people using one account cannot be told apart from the records alone.