Helpful first: Identity alert triage: reconstructing who, what, and how across logs · Logs, alerts, and evidence: why an alert title is a hypothesis, not proof
Key points
- SP 800-61 Rev. 3 uses the six CSF 2.0 Functions in place of the four Rev. 2 phases.
- Explain why an action request (such as an API call returning 504 Gateway Timeout or asynchronous 202 Accepted) is not proof that containment succeeded
- Verify eradication and recovery by querying active session tables, persistence mechanisms, and downstream audit logs
From confirmed triage to active containment
Threat Hunter Nyx confirms that an attacker hijacked the session token of dax.mercer@chronos.orbital. The attacker used it to enroll a rogue authenticator at Meridian Space & Robotics (chronos.orbital). The work then moves from Detect to Respond and Recover. NIST SP 800-61 Rev. 3 (April 2025) is a CSF 2.0 Community Profile.
In the heat of an incident, speed matters, but unverified speed is dangerous. If an analyst clicks "Suspend User" in the dashboard, pastes "User disabled" into the Slack war room, and moves on without checking whether active bearer tokens were actually revoked across downstream APIs, the attacker stays inside the environment while the responders think the fire is out.
| CSF 2.0 Function (Rev. 2 phase) | Primary Operational Goal | Meridian Action on Compromised Identity | Required Verification Proof |
|---|---|---|---|
| 1. Govern, Identify, Protect (Rev. 2: Preparation) | Build playbooks, centralize UTC logs, pre-stage containment APIs, and run tabletop drills | Configure short JWT lifetimes, FIDO2 policies, and one-click session revocation runbooks | Purple-team drill confirms revocation propagates within 60 seconds |
| 2. Detect (Rev. 2: Detection & Analysis) | Correlate logs, determine scope/blast radius, and preserve forensic evidence | Trace every API call, repo clone, and IAM change made by the hijacked sessionId | Complete timeline of affected assets and persistence artifacts |
| 3. Respond and Recover (Rev. 2: Containment, Eradication & Recovery) | Stop active bleeding (short-term containment), remove attacker persistence (eradication), and restore clean access (recovery) | Revoke all refresh/access tokens, delete the rogue MFA device, rotate exposed secrets, and re-enroll Dax on FIDO2 | Fresh GET readback shows 0 active sessions, rogue MFA deleted, and subsequent attacker requests returning 401 |
| 4. Improvement, ID.IM in Identify (Rev. 2: Post-Incident Activity) | Conduct blameless root-cause review and harden controls so the class of attack cannot repeat | Deprecate push MFA in favor of mandatory FIDO2/WebAuthn across all engineering roles | Updated IdP policy verified in production config |
Containment is not eradication: hunting for persistence
Disabling a compromised user password or revoking the initial login session is short-term containment, not eradication. In the three minutes before containment, an attacker routinely plants secondary persistence: registering a second MFA device, minting a long-lived Personal Access Token (PAT), adding an SSH key, or creating a backdoor OAuth application grant.
Short-term containment
Revoke the first session
Time
dwell window
Persistence
second MFA device
Persistence
long-lived Personal Access Token (PAT)
Persistence
SSH key
Persistence
backdoor OAuth application grant
Eradication
Remove each artifact before restoring the account
Eradication requires auditing every resource the compromised session touched during its dwell window and removing every unauthorized artifact before restoring the user’s account.
When the revoke API returns 504 - or why "sent" never equals "applied"
Suppose Nyx’s automated SOAR playbook calls POST /admin/v1/users/dax.mercer/revoke-sessions, and the upstream Identity Provider returns 504 Gateway Timeout (or 202 Accepted for an eventual-consistency queue). Did the revocation happen or not? You cannot know from the command attempt alone.
Even when an IdP returns 200 OK, stateless JWT access tokens with a 60-minute expiration might continue working against downstream microservices that only validate cryptographic signatures locally without checking a revocation list. True verification requires two closed-loop checks: querying the authoritative state (GET /users/dax.mercer/sessions and /factors to confirm empty state) AND watching the API gateway logs to confirm the attacker’s next replay attempt is actively rejected with 401 Unauthorized.
Blameless post-incident improvement
Every incident ends with a structured lessons-learned review. Rather than blaming Dax for approving a push prompt, Meridian uses the incident evidence to eliminate the vulnerable control class - removing phishable push notifications and enforcing origin-bound WebAuthn fleet-wide.
Review
lessons-learned review
Remove
phishable push notifications
Enforce
origin-bound WebAuthn
Scope
The review removes a control class, not a person
CHECK YOUR JUDGMENT
During an active credential-compromise incident at Meridian Space & Robotics (chronos.orbital), a SOAR playbook sends a POST /revoke-tokens request to the Identity Provider, which returns 504 Gateway Timeout. Meanwhile, the attacker had already registered a new Personal Access Token (PAT) two minutes earlier. What must Threat Hunter Nyx do before declaring the account contained and eradicated?
NEXT FIELD LESSON