Build-system implant → signed supply-chain backdoor (SolarWinds-class)
Compromise the target vendor's build server. A small implant rewrites a single source file at compile time — every official signed release downstream now ships the backdoor.
§ Context
Assumed environment: target software vendor signs binaries with a real cert, runs an automated build server, and trusts the result without re-validating source from a separate gold copy. 3CX / SolarWinds class.
§ Steps
- 01Selectively target high-value installsInitial AccessT1078— Valid Accounts
- 02Foothold inside vendor network (phish / VPN cred)Initial AccessT1078— Valid Accounts
- 03Build server emits backdoored signed artefactInitial AccessT1195— Supply Chain Compromise
- 04Subset of installs beacon to attackerCommand and ControlT1071— Application Layer Protocol
- 05Map vendor build infraReconnaissanceW-RECON-GITHUB-DORK— GitHub / GitLab Dorking
- 06Customers auto-update, mass installPersistenceSUP-ACTION-TAG-MUTATION— GitHub Action Tag Mutation
- 07Implant on the build agent (SUNSPOT-class)Initial AccessAPT-SOLARWINDS-BUILD— Build-System Implant (SUNSPOT-class)
§ References
§ Frequently asked
- What is the "Build-system implant → signed supply-chain backdoor (SolarWinds-class)" attack path?
- Compromise the target vendor's build server. A small implant rewrites a single source file at compile time — every official signed release downstream now ships the backdoor. It chains 7 steps drawn from real-world offensive-security techniques.
- What starting position does this attack require?
- The first step is Selectively target high-value installs (T1078) — a initial access primitive. Assumed environment: target software vendor signs binaries with a real cert, runs an automated build server, and trusts the result without re-validating source from a separate gold copy.
- What is the final impact of this kill-chain?
- The final step lands on Implant on the build agent (SUNSPOT-class) (APT-SOLARWINDS-BUILD), which falls under Initial Access. From here, an operator typically pivots into post-exploitation or maintains persistence.
- How can defenders detect or prevent this attack?
- Detection and prevention vary per step. Refer to each linked MITRE ATT&CK entry under "References" — every technique on that page lists defensive controls, detection telemetry, and known threat-actor usage.
§ Related dossiers
- Shared techniques2
Mass SMS phish → Okta-style portal → SaaS sprawl (0ktapus)
Wide SMS phishing campaign targeting employees of ~130 organisations with a single phishlet that captures Okta credentials + push approval. Mass automated logins to Twilio, MailChimp, DoorDash et al.
- Shared techniques2
Dev workstation → cloud backup keys → encrypted vault store (LastPass 2022)
Attacker compromised a single LastPass DevOps engineer's home machine via outdated Plex Media Server, harvested AWS keys for the encrypted-vault backup bucket, exfiltrated production vault data.
- Shared techniques2
AMSI patch → in-memory .NET / PowerShell stager
Patch AmsiScanBuffer in amsi.dll → return clean for any content. Subsequent PowerShell / Office VBA / .NET runtime calls emit attacker code without scanning.
- Shared techniques2
Trusted updater hijack → wormable destructive payload (NotPetya / M.E.Doc)
Compromise a niche third-party vendor (regional tax software, niche industry tooling). Push a malicious update; every customer auto-installs it. Payload spreads via SMB + Mimikatz, wipes drives.
- Shared techniques2
Vish helpdesk → Okta MFA reset → admin → ransomware (MGM-class)
Identify an Okta admin via LinkedIn. Vish the helpdesk pretending to be that admin, get MFA reset. Sign in, plant attacker MFA factor, then push policy changes that disable MFA for chosen apps before mass-deploying ransomware.
- Shared techniques2
Insider admin panel coercion → mass account takeover (Twitter 2020)
Identify employees with access to an internal admin panel. SE / coerce one to use the panel to change target accounts' email + 2FA, then take them over.