Supply-Chain Compromise Tabletop: A Trojanized Signed Update

A software supply-chain compromise turns a trusted relationship into an attack path. The attacker compromises a vendor's build or update process, and a legitimately signed update delivers malicious code to the vendor's customers. Public cases involving trojanized updates to widely used IT management and communications software showed how hard these incidents are: the software was trusted, signed and often highly privileged, and victims had to work out where it ran, what it could reach and whether attackers had used it.

This scenario tests asset inventory, third-party coordination, containment trade-offs, threat hunting and customer communications. It is aimed at technical responders and the executive crisis team, with an emphasis on decisions under uncertainty.

Scenario at a glance

Exercise objectives

1. Determine within a defined time where the affected software is installed, which versions are present and what privileges it holds.
2. Agree the containment approach and decision owner when the affected software supports critical operations.
3. Test coordination with the vendor and use of external advisories from national cybersecurity agencies.
4. Validate the ability to hunt for follow-on activity and to decide when the environment can be trusted again.
5. Rehearse communications to customers who may themselves be affected through your products or services.

Starting situation

Read this aloud to players:

It is Tuesday, 08:00. Your organisation uses a widely deployed IT monitoring and management platform from a well-known vendor. Its agent runs on most servers and many workstations with high privileges, and its central server has credentials to manage network devices. Updates are applied automatically within a week of release.

You also ship a desktop application to your own business customers, built in your CI pipeline, which uses several third-party libraries.

Injects timeline

Module 1 — Disclosure and scope (T+00:00 to T+01:30)

Inject 1. A security research team publishes a report: a signed update of the monitoring platform released six weeks ago contains a backdoor that can receive commands over HTTPS. The report notes that only a subset of installations appear to have been actively used by the attackers.

Inject 2. The vendor confirms the affected version range and recommends disconnecting or powering down the central server until a fixed version is available.

Inject 3. IT operations checks the software inventory: the affected version is on the central server and on roughly 600 agents. They warn that some business units run their own instances not recorded centrally.

Inject 4. The CIO points out that isolating the central server stops production monitoring and the automated patching it drives, during a quarter-end period.

Discussion questions:

• How quickly can you confirm whether you run the affected software and versions? What sources do you trust?
• Who talks to the vendor, and through which channel? Do you have a named contact and a contract clause on security incidents?
• Who decides whether to isolate the central server? What is the risk of leaving it running for an hour? A day?
• How do you find the unrecorded instances?

Module 2 — Hunting and expansion (T+03:00 to T+10:00)

Inject 5. A national cybersecurity agency publishes indicators of compromise (domains, file hashes and behaviours). Proxy logs show your central server made HTTPS connections to one of the listed domains on several days last month.

Inject 6. Threat hunting finds a new directory service account created two weeks ago. It has been used to authenticate from the monitoring server to file servers and a finance system.

Discussion questions:

• What does outbound traffic to a listed domain tell you, and what does it not tell you?
• Do you have enough log retention to look back six weeks? If not, what can you still establish?
• With evidence of hands-on activity, how does the scope change? Do you now treat the directory as compromised?
• Do you need external IR support? Is a retainer in place?
• What do you preserve before rebuilding anything?

Module 3 — Customers, trust and closure (T+24:00 to T+72:00)

Inject 7. Two of your largest customers email their account managers asking whether your desktop application or its update mechanism is affected, and requesting a written statement within 24 hours.

Inject 8. The vendor releases a fixed version but says its investigation of the build environment is ongoing.

Inject 9. The board chair asks the CEO: "Are we clean? When can we tell customers and regulators that we are?"

Discussion questions:

• Can you show that your own build pipeline and product were not affected? What evidence would you use (for example, an inventory of components, build logs, signing key controls)?
• Who approves the customer statement? How do you avoid over-promising?
• Do you install the vendor's fix, rebuild the server from scratch, or replace the product? Who decides?
• What are your criteria for declaring the incident closed? How do you express confidence honestly to the board?
• Do any regulatory, contractual or sector notification obligations apply?

Discussion questions

• Inventory: How complete and current is your software inventory? Who owns it?
• Privilege: Which third-party tools in your environment have domain-level or network-wide privileges?
• Vendor management: Do contracts include security-incident notification, cooperation and evidence-sharing obligations?
• Detection: Would you have noticed the malicious activity without an external report?
• Assurance: Could you answer a customer's supply-chain question about your own product within 24 hours?

Curveballs / optional injects

• The vendor's advisory is revised: more versions are affected than first stated.
• A journalist asks whether you are among the named victims in a government report.
• A second vendor you use announces an unrelated compromise the same week.

Facilitator notes

Expected decisions. A strong team establishes scope quickly from multiple sources, makes a documented, time-bound containment decision, preserves evidence, hunts using published indicators and behaviours rather than hashes alone, escalates to directory-level compromise when evidence supports it, and communicates with customers carefully and factually.

Common pitfalls.

• Waiting for the vendor to tell you whether you were affected.
• Treating "we installed the fixed version" as the end of the incident.
• Relying only on hash-based indicators, which attackers change easily.
• Over-confident customer statements that later have to be corrected.
• No closure criteria, so the incident either never ends or ends by fatigue.

Adapting the audience. For executives, compress Modules 1–2 into briefings and focus on injects 4, 7 and 9. For technical teams, extend Module 2 with specific hunting hypotheses: new services and scheduled tasks, anomalous authentication from the management server, changes to network device configurations.

Evaluating the exercise

Related

• Cloud access key leak scenario
• Designing tabletop injects and the MSEL
• Scoring tabletop exercises
• Glossary: incident commander, traffic light protocol