{
	"id": "4166777b-a5fd-4d72-93ab-2f32e7b9e036",
	"created_at": "2026-04-06T00:21:45.094951Z",
	"updated_at": "2026-04-10T03:21:36.240619Z",
	"deleted_at": null,
	"sha1_hash": "0583253c3a2c664833ef5cb22050e6a952e06493",
	"title": "Detect and prevent the SolarWinds build-time code injection attack",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 48696,
	"plain_text": "Detect and prevent the SolarWinds build-time code injection\r\nattack\r\nBy Ariel Levy\r\nPublished: 2021-02-17 · Archived: 2026-04-05 13:28:42 UTC\r\nPublished February 17 2021 · 3 min. read\r\nWe have developed a patent-pending technology to detect and prevent SolarWinds-style attacks before shipping\r\nbinaries to production, in both on-prem and cloud environments.\r\nIn order to understand how this new capability works technically, let’s briefly examine how the attack was\r\nexecuted and why it went unnoticed for so long.\r\nTHE MOTIVATION\r\nIn late 2020, a complex supply chain attack against SolarWinds made headlines globally. Malicious code that\r\nimplemented a back door was injected into the source code during the build process, exposing every SolarWinds\r\ncustomer to a significant threat. Although supply chain attacks are a known concept, this is the first disclosed\r\ndetection of one at such complexity and vast scale.\r\nInternal and external investigations of the scenario discovered that malware was running on the SolarWinds Orion\r\nIT management build environment and waiting for msbuild.exe (the C# compiler) to run. When a build process\r\nstarted, the malware verified that the build target was SolarWinds.Orion.Core.BusinessLayer.dll. If so, it\r\nimmediately replaced the staged C# files with a version containing the back door’s code before compilation,\r\nresulting in malicious code inside. This dll was later digitally-signed, which resulted in the file avoiding\r\nsignificant scrutiny.\r\nOnce the build environment is penetrated, there are countless methods to influence the resulting product. While\r\nthe pipeline’s input is readable (and testable) code, its output is a digitally-signed binary. Comparing them\r\nin order to identify a build-level attack wasn’t possible … until now.\r\nThe challenge\r\nTaking binary code and restoring it to its original source code is a practically impossible task. Compilation is a\r\ncomplex, non-reversible action. A compiled binary is packed with information, optimizations, and metadata that\r\nare continuously changing. Even if you take the same source code and compile it again a minute later, the binaries\r\nwon’t be identical.\r\nIn addition to the non-readable binary challenge, the variety of CI/CD tools and approaches is extremely broad.\r\nThese tools are used differently by every team (where each approach handles dependencies, common code, and\r\nhttps://blog.apiiro.com/detect-and-prevent-the-solarwinds-build-time-code-injection-attack\r\nPage 1 of 2\n\nadditional resources in a unique way). Add to this the fact that the CI/CD pipeline is designed to be invisible to its\r\nusers and is almost never inspected and you get a huge DevSecOps blind spot\r\nWe think about this from a totally different perspective\r\nThe solution\r\nWith a deep understanding of the source code, it is possible to determine whether or not it matches the relevant\r\nbinary file (based on patent-pending technology). By the time the build process starts, Apiiro will have already\r\nlearned the source code and developer experience using its risk-based AI engine. Once the Apiiro platform knows\r\nall the code components, security controls, logical flows, data types, and their relations, the next phase is to\r\nanalyze the binary.\r\nLet’s take a .NET binary, for example. The Apiiro platform will parse and perform the following actions on the\r\nexecutable files:\r\nLearn all possible logic flows and symbols\r\nClean out all auto-generated compiler logic\r\nAdjust expected differences between runtime versions\r\nAnd more…\r\nWith the normalized entity relations from the binary, Apiiro runs graph comparison algorithms against the same\r\ndata it learned from the source code.\r\nApiiro’s algorithm is also aware of all possible legitimate code changes during compilation (AOP frameworks,\r\noptimizations, etc.) and is able to distinguish only inserted malicious functionality, be it a small configuration\r\nchange or full back door code.\r\nTo protect your organization from the next supply-chain attack, do not allow your vendors to deploy or upgrade\r\ntheir products without:\r\nPerforming the above comparison for every compiled binary to detect source code manipulation\r\nValidate included dependencies, external (using a digital signature) and internal (using contextual\r\nknowledge of all the organization’s repositories)\r\nCompare additional resource files, if present, to their counterparts from the source commit, taking into\r\naccount potential build-time templating processes\r\nThese steps will be done simply by uploading the built binaries to the Apiiro platform using a dedicated API that\r\ncan easily be integrated into every CI/CD pipeline and read-only access to the source control manager.\r\nWhen Apiiro performs this process at the end of every build, you get end-to-end validation that no\r\nunwanted code is injected into your product before shipping to customers\r\nSource: https://blog.apiiro.com/detect-and-prevent-the-solarwinds-build-time-code-injection-attack\r\nhttps://blog.apiiro.com/detect-and-prevent-the-solarwinds-build-time-code-injection-attack\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://blog.apiiro.com/detect-and-prevent-the-solarwinds-build-time-code-injection-attack"
	],
	"report_names": [
		"detect-and-prevent-the-solarwinds-build-time-code-injection-attack"
	],
	"threat_actors": [],
	"ts_created_at": 1775434905,
	"ts_updated_at": 1775791296,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/0583253c3a2c664833ef5cb22050e6a952e06493.pdf",
		"text": "https://archive.orkl.eu/0583253c3a2c664833ef5cb22050e6a952e06493.txt",
		"img": "https://archive.orkl.eu/0583253c3a2c664833ef5cb22050e6a952e06493.jpg"
	}
}