█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Cybersecurity/Incident Response/Tabletop Exercise: Credential Compromise
45 minIntermediate

Tabletop Exercise: Credential Compromise

After this lesson, you will be able to: Lead a tabletop exercise from start to finish, making decisions at each stage of the incident as if you were the IR lead.

Tabletop exercises are how real security teams stress-test their plans without setting anything on fire. This lesson gives you a complete scenario and walks you through the decisions that get made at each phase.

Prerequisites:SIEM Basics with Splunk

What a tabletop is

A tabletop is a written-and-spoken simulation of a security incident. No tools, no logs, just decisions. Participants assume real roles (IR lead, comms, legal, exec sponsor, on-call engineer) and walk through what they would do given the information available at each step. The artefact is a list of decision points where the plan was unclear, the comms didn't work, or the runbooks didn't fit reality, those become the post-tabletop action items.

💡 Scenario: 'Phantom Helpdesk'

It's Tuesday, 9:47 AM. Your CISO forwards an email: 'My password isn't working anymore.' A few minutes later, the helpdesk Slack channel reports 'three more password reset requests in the last hour.' By 10:15 AM, the IAM team confirms: a user has authenticated from a new IP in Lagos. The IP has been seen in OSINT feeds as a known credential-stuffing source. You are the IR lead. Walk through the next 4 hours.

Phase 1, Preparation (already happened, but check)

What was in place that helps you right now?

  1. 1

    Is there an IR playbook for credential compromise? Where is it stored? Can you find it in 30 seconds?

  2. 2

    Is there a known on-call schedule? Who is on shift?

  3. 3

    Is there a pre-approved escalation path to legal and comms? Or do you need an exec sign-off?

  4. 4

    Is MFA enforced? On admin accounts specifically?

  5. 5

    Is there a SIEM that lets you query sign-in events across all users? Do you have query access right now?

Phase 2, Detection and Triage

Confirm scope before sounding the alarm.

  1. 1

    Query the SIEM: how many accounts have signed in from the suspicious IP in the last 30 days?

  2. 2

    Query for any privileged accounts in that set

  3. 3

    Query for MFA prompts that were denied (push fatigue evidence?)

  4. 4

    Identify the BUSINESS IMPACT: which apps does each compromised account have access to?

  5. 5

    Decide if this is a Sev-1 (immediate, board-level), Sev-2 (significant), or Sev-3 (contained); document your reasoning

Phase 3, Containment

Buy time by limiting attacker's options.

  1. 1

    Force a password reset on all confirmed-compromised accounts

  2. 2

    Force a session revocation across SSO (Entra: 'Revoke all sessions'; Okta: similar)

  3. 3

    For users that show MFA fatigue evidence, also reset MFA factors

  4. 4

    If there's CFOO/CTO/CEO involvement (privileged accounts), notify Legal and Comms immediately

  5. 5

    Draft a one-paragraph internal Slack update for the wider engineering channel; have your manager sign off before posting

Phase 4, Eradication and Recovery

Remove the threat and restore trust.

  1. 1

    Check sign-in logs for anything the compromised accounts did since the first suspicious login. Were emails sent? Files downloaded?

  2. 2

    If data was accessed, document what and notify the data owners + Legal

  3. 3

    Verify all reset accounts can sign back in cleanly

  4. 4

    Review firewall and IAM rules for changes the attacker might have made (new app passwords, new MFA methods, OAuth grant additions)

  5. 5

    Decide on the comms posture: do affected users get a personalised email? An all-hands announcement? Both?

Phase 5, Post-Incident

Turn this into improvement.

  1. 1

    Write the IR report (1-2 pages, see the cs-vuln-cve template, adapt for IR)

  2. 2

    Identify root cause: was MFA on those accounts? Was the SIEM query you needed available? Was the playbook usable?

  3. 3

    List 3-5 concrete action items: 'Enable phishing-resistant MFA on all admin accounts by <date>'; 'Add CISA KEV-style monitoring for credential-stuffing IPs.'

  4. 4

    Schedule a 30-minute team-wide review of the incident within 2 weeks

  5. 5

    File each action item as a Jira ticket with owner and deadline

Common mistakes only experienced IR leads catch

Treating containment as eradication. Resetting passwords doesn't remove a backdoor. Forgetting comms. Engineers blast updates internally; legal and comms find out from a board member, not great. No timeline. Every IR report needs a timeline (when did detection occur, when did containment occur, etc.). Reconstruct it from logs as you go. Skipping the post-incident review. The action items are the actual deliverable; everything before was just getting to the table. Treating tabletops as performance. The whole point is to find gaps; if you 'pass' a tabletop, you ran it wrong.

Quick Check

What's the deliverable of a tabletop?

Pick the cleanest answer.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Hands-on: SIEM Basics with Splunk
Back to Incident Response
Incident Response Resources and Next Steps→