Supply Chain Compromise Playbook
Responding to a compromised software update, malicious dependency, or managed service provider intrusion — scoping the blast radius across customers, coordinating with the vendor, and deciding when to remove a trusted tool from your environment.
CISA releases an advisory at 11 PM: a widely-used IT management software vendor (call it "SolarMonitor") was compromised. Malicious code was shipped in versions 9.2.1 through 9.2.4. Your asset management system shows 14 machines running SolarMonitor 9.2.3 — all of them Windows servers in your production environment. The malicious update was installed 18 days ago. The software runs as SYSTEM. This isn't a "you were targeted" scenario — you're one of thousands of organizations affected. But the response is still yours to run: scope what the malicious code did in your environment, determine if your environment was actively exploited or just at risk, and decide whether to remove the compromised software.
Initial Scope Assessment
Supply Chain IR Decision Tree
═══════════════════════════════════════════════════════════════════
Vendor compromise announced
│
▼
Do you run the affected software?
YES → Check which versions and on how many hosts
NO → Verify via software inventory; if confirmed none → close
│
▼
What versions are affected?
Check your deployed version against vendor advisory
│
├── Not affected version → verify, document, close
└── Affected version → continue below
│
▼
What does the malicious code do? (from vendor advisory or threat intel):
• Does it beacon immediately (active C2) or wait for a trigger?
• What permissions does it require / does it escalate?
• Is there a way to tell if YOU were specifically targeted
(most supply chain attacks have staged activation — many
organizations installed it but only some were actively exploited)
Were you specifically exploited?
Check: EDR for C2 traffic from the software's process
Firewall logs for outbound connections from affected hosts
Memory for attacker tooling in the software's process
│
├── Active exploitation confirmed → full IR response
└── Software present but no active exploitation indicators
→ Still remove/disable; hunt for confirmation either way
Supply Chain Hunt Queries
# Hunt for IOCs specific to the supply chain compromise
# IOCs come from CISA advisory, vendor advisory, or threat intel community
# Step 1: Identify all hosts running affected software
$affectedVersions = @("9.2.1","9.2.2","9.2.3","9.2.4")
$computers = Get-ADComputer -Filter * | Select-Object -ExpandProperty Name
$affected = Invoke-Command -ComputerName $computers -ScriptBlock {
param($versions)
$sw = Get-WmiObject Win32_Product |
Where-Object { $_.Name -like "*SolarMonitor*" }
if ($sw -and ($versions -contains $sw.Version)) {
[PSCustomObject]@{
Host = $env:COMPUTERNAME
Version = $sw.Version
Install = $sw.InstallDate
}
}
} -ArgumentList $affectedVersions -ErrorAction SilentlyContinue
$affected | Where-Object { $_ } | Format-Table
# Step 2: Hunt for known-bad C2 IPs in firewall/network logs
# (Replace with actual IOCs from advisory)
$c2IPs = @("185.220.101.47","45.142.212.100")
Write-Host "Search SIEM for outbound connections to: $($c2IPs -join ', ')"
# Step 3: Check if affected software's process made outbound connections
# Sysmon Event 3 — Network Connection by the affected software
Get-WinEvent -FilterHashtable @{
LogName = "Microsoft-Windows-Sysmon/Operational"
Id = 3
} -ErrorAction SilentlyContinue | ForEach-Object {
$xml = [xml]$_.ToXml()
$d = $xml.Event.EventData.Data
$img = ($d | Where-Object Name -eq "Image")."#text"
$dest = ($d | Where-Object Name -eq "DestinationIp")."#text"
if ($img -like "*SolarMonitor*") {
[PSCustomObject]@{
Time = $_.TimeCreated
Image = $img
Dest = $dest
Port = ($d | Where-Object Name -eq "DestinationPort")."#text"
}
}
} | Where-Object { $_ } | Format-TableCoordinating With the Compromised Vendor
In supply chain incidents, the vendor is simultaneously a victim and a source of intelligence. Their response quality varies enormously.
| What to ask the vendor | Why you need it |
|---|---|
| What exactly does the malicious code do? (Technical details) | Determines whether you need a full IR response or just a software update |
| When was the malicious code introduced and when was it removed from distribution? | Determines your exposure window |
| Is there a way to tell whether a specific environment was actively targeted? | Most supply chain attacks have staged activation — not all installs were exploited. C2 check-in logs at the vendor may tell you if your environment called home. |
| What IOCs should we hunt for? | Specific C2 domains/IPs, file hashes, registry keys, or process names to hunt in SIEM and EDR |
| What is the remediation? (Clean version, workaround, removal tool?) | Needed for eradication planning |
Remove, Update, or Isolate?
| Scenario | Recommended action |
|---|---|
| Vendor has released a clean update, no active exploitation confirmed | Update to clean version immediately; hunt for any residual IOCs after update; continue monitoring |
| Active exploitation confirmed in your environment | Isolate affected hosts via EDR; treat as full IR incident — eradication and persistence hunt required before returning to service |
| Vendor has not yet released a clean version | Disable or isolate the software; apply network controls to prevent C2 communications from affected hosts; monitor until clean version is available |
| No clean version will be released (vendor went out of business, open source with no maintainer) | Remove the software; replace with alternative; treat affected hosts as compromised and run full eradication before returning to production |
Supply chain attackers typically install malicious code that beacons once to a staging server and then waits. If your environment didn't receive a "stage 2" payload, your EDR and firewall logs will show minimal activity — the initial staging beacon may have looked like a routine software update check. "No stage 2 payload installed" is not the same as "the affected software never ran malicious code." The malicious code ran on every machine that installed the affected version. What varies is whether the attacker chose to activate it further. Assume the worst, verify the assumption through hunting, and document what you found — not what you assumed.
Q & A
Q: A managed service provider (MSP) that manages your IT infrastructure was compromised. The MSP has admin access to your AD and all servers. How is this different from a regular supply chain compromise?
Significantly different — and significantly worse. The MSP had privileged access to your entire environment, not just one software product. The attacker, through the MSP, had the equivalent of a Domain Admin account in your environment. This means: (1) Assume full domain compromise — same as if you detected a Domain Admin account compromise directly. (2) The dwell time is not limited by when the specific attack tool was deployed — it's however long the MSP's compromised account existed. (3) The MSP cannot help you with the investigation while they're simultaneously a victim — your IR team must handle this independently, potentially without the MSP's cooperation (or at least with significant friction). (4) Every system the MSP managed must be treated as potentially compromised. Engage an external IR firm with no connection to the MSP. Preserve evidence before the MSP takes any remediation action in your environment.