Supply Chain Attack Detection Playbook: Catching Implants in Flight

SUNBURST's primary tell was DNS. The implant beaconed to subdomains of avsvmcloud.com generated from victim-specific data, encoded in DNS labels. Detection requires baselining outbound DNS per process and alerting on processes that suddenly query never-before-seen domains, especially when the parent process is a vendor binary that historically only contacted vendor update servers. In Splunk or Sentinel, build a process-to-DNS-domain pairing baseline over 30 days, then alert when a vendor agent (SolarWinds Orion, Kaseya VSA, ConnectWise ScreenConnect, any RMM) initiates DNS to a domain not in its historical set. Beacon patterns are the second signal: regular jitter-bounded outbound connections at 5 to 30 minute intervals, typically with low byte counts on the outbound leg. RITA from Active Countermeasures is the open-source standard for beacon detection from Zeek logs; commercial NDR platforms (ExtraHop, Vectra, Darktrace) build the same logic in. Process parent-child relationships matter too: vendor agents should not be spawning PowerShell, cmd.exe, or wmic. Build EDR detections that alert on any child process of common RMM and monitoring agents that falls outside their normal subprocess set. Sysmon Event ID 1 with parent process filtering is the foundation; Splunk's PsTree or KQL's process_tree functions help analysts pivot.

The Supply chain Levels for Software Artifacts (SLSA) framework provides a maturity model with four levels of build integrity. Level 1 requires that the build is scripted and produces provenance metadata. Level 2 requires that the build runs on a hosted build service that generates signed provenance. Level 3 requires source and build platform hardening, including non-falsifiable provenance. Level 4 requires two-party review of all changes and hermetic, reproducible builds. Most organizations should target SLSA Level 2 within a year and Level 3 within two. The practical implementation in GitHub Actions: use the slsa-framework/slsa-github-generator workflow to produce in-toto attestations, sign them with Sigstore's cosign, and store them as OCI artifacts alongside the container image. At deployment time, verify the attestation with cosign verify-attestation before allowing the image to run. For Kubernetes, the policy-controller admission controller enforces this at the cluster boundary. Reproducible builds are the gold standard: if two independent builds of the same source produce byte-identical outputs, you have strong evidence that the build was not tampered with. Achieving reproducibility requires deterministic timestamps, sorted file orderings, and pinned toolchain versions; the Reproducible Builds project documents the techniques per language.

Dependency confusion exploits the default resolution behavior of package managers: when both a public and private package share a name, most package managers default to the higher version number, regardless of source. The 2021 research from Alex Birsan demonstrated this against PayPal, Apple, Microsoft, and others. Detection has two prongs. First, manifest validation: every package.json, requirements.txt, go.mod, or Cargo.toml in your repos should be parsed and compared against an allowlist of internal package names with expected scopes. Any internal package name that exists publicly without your control is a critical finding; either claim the public name or rename internally. Second, registry monitoring: subscribe to npm, PyPI, and RubyGems advisory feeds, and additionally run a daily diff of new versions of packages you depend on against expected publishers. Socket.dev, Phylum, and Snyk Advisor offer this as a service; the open-source dep-scan tool from OWASP works for smaller catalogs. Typosquatting detection is similar: levenshtein-distance comparison of every newly imported package name against your known dependency set surfaces lookalikes (requets vs requests, urllib3 vs urllib-3). Block at the proxy or registry level when you find one.

When you confirm a malicious package version made it into production, the response splits into containment and blast radius assessment. Blast radius first: identify every artifact (container image, binary, deployment) that consumed the compromised version. SBOM data is essential here; if you don't have CycloneDX or SPDX SBOMs for every production artifact, this step takes days instead of hours. Once you know the affected artifact set, the decision is rollback versus isolation. Rollback is cleaner: deploy the previous known-good version and revoke any secrets the compromised version had access to. Isolation is appropriate when rollback is impossible (the older version has its own CVE, or rollback breaks data compatibility). Isolation means network-restricting the affected workloads to deny outbound except essential endpoints, while you assess what the malicious code did. Always assume credential exposure: rotate every secret the workload had in memory, including service account tokens, API keys, database credentials, and TLS private keys if they were unwrapped in memory. The window between malicious code execution and your detection is the window in which credentials may have been exfiltrated; treat all of them as burned.

GitHub Actions has been the vector for multiple recent supply chain incidents (codecov, tj-actions/changed-files). Three hardening practices cut most of the risk. First, pin every third-party action to a commit SHA, not a tag. Tags are mutable; SHAs are not. Replace uses: actions/checkout@v4 with uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11. Use Dependabot's version-update for github-actions to keep SHAs current with reviewed PRs. Second, audit GITHUB_TOKEN permissions per workflow. The default is permissive; explicitly set permissions: contents: read at the workflow level and grant write only to the specific jobs that need it. Third, restrict which actions can run: in organization settings, configure Actions permissions to allow only verified creators plus an explicit allowlist of approved community actions. For sensitive workflows (release, deploy), require approval before any action runs, and run those workflows on self-hosted runners that have no network access to public registries except through a monitored proxy. OIDC federation with cloud providers eliminates long-lived AWS or GCP credentials from secrets; configure that wherever possible and audit any remaining static cloud credentials in secrets monthly.

The defining behavior of SolarWinds-style implants is that they execute in the context of a legitimate vendor process. Generic malware detection misses this because the parent process is signed and known-good. The detection has to target what happens after update: an EDR rule that fires when a vendor update process (any installer signed by SolarWinds, Kaseya, ConnectWise, etc.) writes a binary to disk outside its documented install path, or when a vendor agent's child process writes to %TEMP%, %APPDATA%, or unusual program directories. CrowdStrike Falcon's Custom IOA framework, SentinelOne's STAR rules, and Microsoft Defender's custom detection rules in Defender XDR all support this kind of behavioral logic. The detection rule should include the binary's hash, the parent process, and the write path; tune by allowlisting known-good update behaviors per vendor over a 30-day baseline. Pair with a deception layer: planted credentials in vendor agent process memory, planted DNS canary entries that vendor agents shouldn't query. When a vendor agent queries a canary domain, that is high-confidence evidence of compromise. CanaryTokens from Thinkst offers this for free; commercial deception platforms (Illusive, Attivo, now part of SentinelOne) integrate deeper.