Tabletop Exercise Template: Simulating Combined Supply-Chain and Identity Attacks for UK IT Teams

A modern incident response plan cannot treat supply-chain compromise and identity theft as separate problems. In practice, attackers increasingly blend the two: a trusted dependency is tampered with, a developer or admin endpoint is infected with an infostealer, and stolen session cookies are used to bypass MFA and move quietly through cloud, SaaS, and VPN environments. This guide gives UK IT teams a ready-to-run tabletop exercise built around that exact pattern, with objectives, injects, detection checkpoints, decision points, response metrics, and remediation work you can turn into a playbook update. If you are improving remote-access resilience alongside detection and response, you may also want to review our guides on multi-factor authentication in legacy systems and observability for logs, metrics, and traces as you design the exercise.

For UK organisations, the stakes are practical as well as technical. A compromise that begins in a developer workflow or CI pipeline can quickly spill into Microsoft 365, AWS, VPN concentrators, and customer-facing systems, creating UK GDPR exposure, contractual reporting obligations, and business interruption. Recent reporting around a Trivy supply-chain attack shows why trust in build tooling matters: even a security tool in the software delivery chain can become part of the attack surface. The tabletop below is deliberately realistic, vendor-neutral, and designed for UK IT teams that need to test people, process, and telemetry together rather than in isolated silos.

1) Why this tabletop matters now

Supply-chain compromise is no longer just a developer problem

Attackers target trusted software components because the blast radius is huge and defenders often assume the package, plugin, or scanner is benign. In a blended scenario, a dependency compromise can seed backdoored artifacts, alter telemetry, or open a path into build systems used by multiple business units. This is especially dangerous when the affected environment has weak secrets hygiene, shared admin accounts, or stale service credentials that can be replayed after the initial foothold. The exercise should therefore test not just code review, but also how quickly your team can isolate a build system, invalidate secrets, and verify whether the compromised tooling reached production.

Infostealers turn “successful login” into false comfort

Infostealers are effective because they steal something more useful than a password: a live browser session, refresh token, or exported cookie jar. That means an attacker may not need to trigger MFA at all, especially if the stolen session is already trusted by the IdP or remote-access gateway. Huntress’ public material on infostealers makes the core point well: identity theft bypasses the assumptions many controls are built on. Your tabletop should explicitly force the team to ask, “Is this login legitimate, or is it a hijacked session?” rather than only asking whether a password was changed.

UK teams need playbook-ready decisions, not theory

Many organisations have incident response documents that look thorough but are too abstract to guide action under pressure. A useful tabletop forces the team to decide who disables accounts, who revokes tokens, who isolates endpoints, and who contacts legal, privacy, and leadership. It should also create an audit trail of timing: when the first indicator appeared, when containment began, and when the business was told. If you are still maturing your process, pairing this exercise with a structured approach to metrics that drive real decisions can help you define response KPIs that matter to leadership rather than just security analysts.

2) Exercise overview: the scenario you will run

Scenario summary

During a routine software update cycle, a build-time security tool used in a container image workflow is suspected of being tampered with. Within hours, one developer endpoint shows signs of an infostealer infection, and a cloud identity platform logs a suspicious session from an unusual ASN using a cookie that should already have expired. The attacker appears to be combining supply-chain access with stolen browser sessions to impersonate internal users, enumerate cloud resources, and retrieve sensitive data. The team must determine whether the compromise is limited to a single workstation, a CI/CD lane, or the broader identity plane.

Exercise goals

The primary goal is to test whether your organisation can detect the blend of initial-access vectors before the attacker establishes persistence. Secondary goals include validating token revocation procedures, proving endpoint isolation paths, and measuring the speed at which cloud, endpoint, and identity teams can share corroborating evidence. A strong tabletop also tests whether incident commanders can translate raw alerts into business decisions such as shutting down a build pipeline, pausing remote access for a user group, or forcing password resets on a subset of privileged accounts. These goals are the foundation of a real playbook, not just a training exercise.

Target audience and roles

This scenario is built for UK IT teams, SOC analysts, incident responders, platform engineers, and service owners. Include at least one representative from identity administration, cloud operations, endpoint management, legal/compliance, and comms. If your remote access stack is still evolving, it may help to review a broader procurement and architecture lens, such as our guide to what to look for beyond the spec sheet, because remote access and endpoint trust are now inseparable from operational management. The more cross-functional the room, the more realistic the decisions become.

3) Pre-brief: what you need before you start

Define the systems in scope

Before the exercise, identify the real systems you want to simulate: SSO/IdP, M365 or Google Workspace, endpoint detection and response, VPN or ZTNA, CI/CD, source control, and cloud control planes such as AWS or Azure. Map the owner for each system and write down who can take emergency action without waiting for approval. The tabletop works best when participants can say, “I know exactly who can revoke a session token, who can isolate a device, and who can pause deployments.” Without that clarity, the exercise becomes a discussion about org charts instead of incident handling.

Gather current telemetry and logging gaps

Ask the team what they can currently see if a session cookie is replayed from a new device or geography. Can they correlate device posture with sign-in anomalies, or do they only get a generic “successful login” event? Can they identify a developer workstation that has browser credential stores, password vaults, or cloud CLI tokens exposed? Observability matters here, and our guide to logs, metrics, and traces that matter is useful as a model: you want alerts that tell a story, not disconnected noise.

Establish exercise rules and timings

A good tabletop runs for 90 to 120 minutes with a facilitator and a scribe. The facilitator should introduce injects on a timed schedule and keep pressure realistic, while the scribe captures decisions, assumptions, and gaps. Give participants a clear rule: they can request more detail, but they must act using the information available at that moment. If you want to benchmark improvements over time, follow a metrics framework similar in discipline to backtesting a system with robustness checks—you are testing process reliability, not just whether the team “felt” prepared.

4) The tabletop scenario: combined supply-chain and identity attack

Phase 1: suspicious build activity

The scenario begins when a developer reports an unexpected warning after updating a build dependency used in a container pipeline. A security scanner emits unusual behavior, and the pipeline starts producing artefacts with subtle metadata changes that do not match prior releases. The first decision point is whether the team treats this as a false positive, a developer error, or a possible supply-chain compromise. Encourage the team to ask whether recent commits, dependency lockfiles, and build runners were altered, and whether any secrets were available to the build environment.

Phase 2: endpoint infection and token theft

Shortly after, one developer workstation begins showing suspicious browser activity, strange new startup entries, and evidence of credential scraping. The user says they clicked a “plugin update” prompt and then noticed their browser signed them out. On the SOC side, the analyst sees a valid session cookie being reused from another device, followed by mailbox access and cloud console navigation that bypasses MFA prompts. This is where an infostealer changes the problem from endpoint compromise into identity compromise, and the correct response is usually not just a password reset but a token invalidation and device containment sequence.

Phase 3: lateral movement through identity trust

Using the stolen session and any cached credentials, the attacker attempts to enumerate cloud resources, retrieve secrets from a repository, and access shared documents containing architecture diagrams and customer data. The attacker may also look for remote-access footholds, especially if your organisation relies on long-lived VPN sessions or over-permissive groups. If your environment still contains legacy remote access dependencies, use this as a prompt to test how quickly you can enforce stricter MFA policies, device checks, and session lifetime limits. For teams modernising remote access, our guide on integrating MFA in legacy systems can help frame practical control points.

5) Injects: the exact messages to deliver during the exercise

Inject 1: build pipeline anomaly

Facilitator message: “The CI job for a frequently deployed service now produces an image hash that differs from the expected value, even though the code diff is minimal. A security tool in the pipeline has been updated recently.” Ask the team what they do first, who is informed, and whether new deployments are paused. A good answer should include pipeline containment, build log preservation, and a check of whether the dependency source or scanner artefact was tampered with. If the team jumps immediately to a full shutdown, explore whether they have a risk-based threshold for halting releases.

Inject 2: unusual sign-in event

Facilitator message: “An identity alert shows a successful sign-in from a UK user account minutes after a sign-in from a different country. MFA is marked satisfied, but the session includes browser cookies and a user-agent that has never been seen before.” The team should recognise this as a possible session replay or token theft event, not a normal travel alert. Their response should include revoking sessions, checking concurrent logins, and reviewing whether the endpoint that originated the original session is compromised. This inject tests whether the team understands that a session cookie can be the real key, not the password.

Inject 3: endpoint detection clue

Facilitator message: “EDR flags a browser process spawning PowerShell and writing to a suspicious folder under the user profile.” This is a classic sign of an infostealer or post-exploitation script, and it should trigger endpoint isolation, memory capture if feasible, and evidence preservation. The team should also consider whether any browser-stored credentials, saved passwords, or API tokens are now exposed. If your team uses a managed detection service, compare how quickly the alert would reach analysts versus a user raising a ticket after the damage is already done.

Inject 4: cloud access escalation

Facilitator message: “Cloud audit logs show the attacker listing storage buckets and attempting to access backup exports. They also query IAM roles associated with deployment automation.” This inject should force the team to evaluate blast radius in cloud accounts, not just on the initial endpoint. Ask whether service principals, access keys, and role assumptions need revocation, and whether privileged sessions should be re-authenticated. For a more formal way to debate control effectiveness with stakeholders, our article on vendor KPIs and SLAs offers a useful mindset: insist on measurable outcomes, not vague assurances.

6) Detection checkpoints: what “good” looks like

Checkpoint 1: identity anomalies are correlated quickly

By the 10-15 minute mark, the team should be able to correlate abnormal sign-in geography, token reuse, and device mismatch. If the only conclusion is “MFA succeeded,” the organisation is missing the key question: what token or session is being trusted, and from where? Mature teams will review session age, device posture, impossible-travel patterns, and authentication context, then decide whether to revoke sessions immediately. This is the point where identity monitoring becomes more valuable than password policy alone.

Checkpoint 2: endpoint and identity teams share evidence

The endpoint analyst should be able to say whether the affected machine shows signs of credential theft, browser tampering, or persistence. The identity team should be able to say whether the same user has other active sessions, delegated permissions, or risky OAuth grants. If these teams are operating separately, the attacker benefits from the gap. Cross-functional evidence sharing is often the difference between containing a local infection and preventing a wider account-takeover event.

Checkpoint 3: cloud and build systems are protected in parallel

Once the team sees a possible supply-chain issue, they should not only isolate the infected endpoint but also freeze release pipelines, validate artefact integrity, and review which repositories and secrets may have been exposed. If the environment uses cloud-native build infrastructure, the team should inspect runner logs, credentials, and image provenance. This scenario intentionally blends build trust and identity trust so that defenders are forced to work both attack paths at once. For comparison, the Trivy supply-chain breach report is a reminder that security tools themselves can become part of the attack chain.

Checkpoint 4: communications and regulatory response are triggered early

UK teams should decide when the issue becomes a reportable incident, who engages legal counsel, and whether external notices are required based on the data implicated. Even if the breach scope is still being confirmed, you should have a line of sight to likely obligations under UK GDPR and contractual notification duties. A tabletop is successful when comms, legal, and leadership are part of the simulation before the team has “perfect” evidence. Waiting for certainty is often how breaches become worse.

7) Metrics: how to measure exercise performance

Time-to-detect and time-to-triage

Track how long it takes participants to identify that more than one attack vector is involved. Time-to-detect should measure the first moment the team recognises a blended compromise, while time-to-triage should measure when they can articulate the likely initial access, affected assets, and containment priorities. If detection takes too long, ask whether alerting is too fragmented or whether analysts lack the right context. You can borrow the same discipline used in practical authority-building metrics: focus on signal quality, not vanity indicators.

Time-to-contain and time-to-revoke

Measure how quickly the team isolates the infected endpoint, disables the compromised account, and revokes all active sessions. A modern identity incident often requires multiple containment actions, not one. If the team only resets a password, the attacker may continue using a still-valid token. This metric should include the latency between detection and the actual enforcement action, because “we decided to revoke” is not the same as “the token is dead.”

Time-to-communicate and decision latency

Log when the incident commander notified leadership, when legal was engaged, and when business owners were told to expect service changes. Decision latency matters because organisations often know enough to act long before they feel comfortable doing so. A well-run tabletop identifies the minimum evidence threshold required for containment decisions. For organisations building procurement or operational cases, the discipline is similar to a data-driven business case: the goal is not perfection, it is decision-quality evidence at the right time.

8) Technical response playbook: what the team should do

Contain the endpoint first, but do not stop there

If an infostealer is suspected, isolate the endpoint from the network, preserve volatile evidence if your process allows, and determine whether the user’s browser, password store, and local tokens were exposed. Reimage decisions should be made based on policy and severity, but the key is not to let the endpoint remain a bridge to identity compromise. Check for browser profile theft, sync-account abuse, and any exported session data. The objective is to break the attacker’s ability to continue using the machine as a credential factory.

Revoke sessions and inspect identity artefacts

Invalidate current sessions, revoke refresh tokens where supported, and check for suspicious OAuth app grants, service principals, and delegated permissions. Review identity logs for unusual user-agent strings, impossible travel, and repeated access to sensitive apps. If your system supports conditional access, force re-evaluation for risky users and device classes. This is where identity threat detection and response become operationally meaningful rather than merely descriptive.

Freeze build trust and verify artefact lineage

Pause deployments from any pipeline that may have touched the compromised tool or dependency. Rebuild from known-good sources, compare hashes, and inspect whether artefacts were signed or provenance-verified. If a tool in your build chain was compromised, treat the surrounding pipeline as suspicious until proven otherwise. For teams making broader toolchain decisions, our guide on ranking integrations by GitHub velocity is a helpful reminder to prefer ecosystems with strong change visibility and maintenance signals.

Notify, coordinate, and document

Document every containment action with timestamps, owners, and dependencies. If user-facing systems are affected, prepare status updates that are honest but not speculative. If personal data or customer data could have been accessed, start the legal and privacy review early rather than after forensic work is complete. Better incident handling is usually a combination of technical containment and disciplined communication.

9) Post-exercise remediation: convert the tabletop into lasting control improvements

Close the identity gaps

After the exercise, assess whether your environment can distinguish a legitimate login from a replayed session cookie. If not, prioritise improvements in identity telemetry, device binding, conditional access, and session revocation processes. Review whether privileged accounts have shorter session lifetimes than standard users and whether administrator workflows are separated from day-to-day browsing. In many organisations, session control becomes the weak link only after an incident exposes it.

Harden the endpoint and browser layer

Implement policies that reduce credential exposure on user devices, including browser hardening, protected storage, and admin-rights minimisation. Infostealers succeed because users work in the browser all day and browsers hold valuable state, including passwords and active logins. Set up controls to flag suspicious downloads, credential-dumping behaviour, and unsigned executables in user profiles. If you need a broader lens on durable technical choices, see our guide on MFA integration and use it to identify gaps in your current rollout.

Improve resilience in the supply chain

Review dependency pinning, package provenance, code signing, SBOM coverage, and the trust model of every build-time security tool. A compromise like the one highlighted in the Trivy supply-chain attack demonstrates that scanners and dependencies themselves must be verified. Introduce release gates that fail closed when artefact integrity is uncertain, and rehearse a fast rollback path. If you buy third-party tools, do so with security telemetry and transparency in mind, much like the due-diligence mindset in vendor negotiation checklists.

Formalise response metrics and run again

Use the results to establish targets for time-to-detect, time-to-contain, time-to-revoke, and time-to-communicate. Then rerun the tabletop in 60 to 90 days with updated injects to prove improvement. The best programmes treat incidents and simulations like an engineering cycle: identify, fix, retest, and measure. If you want to sharpen that habit, our article on backtesting with robustness checks offers a strong analogy for validating process changes under different conditions.

10) Comparison table: controls to validate during the exercise

11) Facilitator notes: how to make the exercise feel real

Use realistic tension, not chaos

The goal is not to overwhelm participants with noise; it is to make the attack path feel believable. Keep injects aligned with what a real attacker would do: steal identity material, use it quietly, and then look for data or privileged systems. Add pressure by introducing a business stakeholder asking whether a release can still ship, or whether remote work access will be interrupted for an entire team. That tension forces participants to balance security with business continuity, which is exactly what UK IT leaders face in live incidents.

Encourage “show me” responses

Ask participants to describe the exact dashboard, log source, or console they would use to confirm their suspicion. In a mature team, answers should be concrete: “I’d check sign-in logs, revocation status, and EDR telemetry,” not “I’d look into it.” This creates a more useful after-action report and reveals training gaps quickly. If your team tends to rely on one platform, the exercise can show whether that dependency is healthy or brittle.

Capture decisions as policy inputs

Every important decision made in the exercise should become an item for an incident playbook, runbook, or control improvement. If the team debates who can revoke sessions, make that authority explicit. If they are unsure when to stop deployments, define the trigger. If they cannot tell whether a user’s browser session is hijacked, work out what telemetry or tooling would change that. Good tabletop design always feeds back into policy and engineering.

12) Final takeaways for UK IT teams

Identity is the new perimeter, but supply chain is the new foothold

This exercise works because it reflects the way attackers actually operate: they get in through trusted code, trusted tools, or trusted users, then use stolen identity material to stay hidden. A single password reset or endpoint reimage is rarely enough when the attacker has both a foothold and a valid session. The right defensive posture combines identity telemetry, endpoint containment, artefact verification, and rapid cross-team coordination. That is the practical meaning of threat detection and response in 2026.

Tabletops should produce measurable improvements

If your tabletop ends with “we need to be more careful,” it has failed. It should end with named owners, timestamped gaps, and a list of playbook changes. The real win is when the next simulation shows faster containment, cleaner evidence, and a shorter path from alert to action. Over time, that is how UK IT teams reduce risk without adding unnecessary friction for users.

Use the exercise as a procurement and architecture benchmark

The scenario also helps you evaluate vendors. Can a platform spot infostealer signals before account abuse escalates? Can it revoke sessions fast enough to matter? Can it correlate endpoint and identity telemetry without a pile of manual work? Those questions are often more important than feature checklists. If you are comparing tools or designing a future-state stack, broader strategic thinking like the one in buyability-focused KPI design can help you evaluate outcomes rather than marketing claims.

Pro Tip: The fastest way to improve this tabletop is to time the gap between “we think this is token theft” and “the token is actually revoked.” That interval is where attackers win or lose.

The main objective is to test whether your team can detect and contain a blended attack that starts with supply-chain compromise and then pivots into identity theft via infostealer-infected endpoints and stolen session cookies. It is designed to reveal gaps in coordination, token revocation, endpoint containment, and build pipeline trust.

How long should the tabletop take?

A realistic session takes 90 to 120 minutes, including debrief. That gives enough time for injects, discussion, and decision-making without turning the event into a half-day workshop. If your team is new to tabletop exercises, start shorter and increase complexity in later sessions.

Do we need a dedicated incident commander?

Yes. Even for a simulation, a single incident commander helps keep decisions clear and avoids multiple people giving conflicting instructions. The exercise should test whether the commander can coordinate security, IT, legal, and business stakeholders under pressure.

What should we measure during the exercise?

At minimum, measure time-to-detect, time-to-triage, time-to-contain, time-to-revoke sessions, and time-to-communicate. Those metrics tell you whether the organisation can actually respond quickly enough to matter, not just whether it can talk about incident response.

How often should UK organisations run this scenario?

Most teams should run it at least annually, and ideally after major changes to identity systems, remote access, CI/CD, or cloud tooling. If you’ve recently introduced new SSO integrations, VPN/ZTNA changes, or endpoint controls, rerun the exercise to validate that the new architecture supports fast containment.

What is the biggest mistake teams make in this scenario?

The most common mistake is treating it like one incident instead of a chained attack. Teams may reset passwords or isolate one device and assume the problem is solved, while a stolen session or compromised pipeline still gives the attacker a path forward.

Related Reading

• Hands-On Guide to Integrating Multi-Factor Authentication in Legacy Systems - A practical follow-on for strengthening identity controls after this exercise.
• Observability for Healthcare Middleware: Logs, Metrics, and Traces That Matter - Useful thinking for building cross-system detection and response visibility.
• European Commission Confirms Data Breach Linked to Trivy Supply Chain Attack - A timely example of why build-tool trust deserves scrutiny.
• Vendor negotiation checklist for AI infrastructure: KPIs and SLAs engineering teams should demand - A strong framework for evaluating response and detection vendors.
• Backtest an IBD-Style Momentum System: Pitfalls, Metrics, and Robustness Checks - A useful analogue for validating tabletop outcomes with repeatable metrics.