Scene 1: What Is a Malicious Update?
Marcus is presenting to his team after a month-long incident investigation. He opens with a question: "What is the single most trusted thing you let into your organization every week?" The team offers answers — emails, VPN connections. Marcus shakes his head. "Software updates." He explains: every organization updates software constantly. Operating systems, security tools, productivity applications, firmware. Updates are trusted by design — the whole point of an update is to improve or fix the software, and security teams are trained to install them promptly.
"An attacker who understands this," Marcus says, "doesn't need to find a way through your firewall. They find a way into the update itself." A malicious update is a software package that appears to come from a legitimate vendor — and may in fact pass all of the vendor's normal delivery mechanisms — but contains code the attacker inserted before or during distribution. The recipient installs it willingly, trusting the source.
Scene 2: How the Attack Works
Marcus draws a pipeline on the whiteboard: Source Code → Build System → Package → Signing → Distribution → Client Install. "An update has to pass through all of these stages," he says. "The attacker doesn't have to attack the end user at all. They attack one of these stages instead." He describes the options. Compromise the source code repository — insert malicious code that gets compiled into the next legitimate build. Compromise the build system — inject code during compilation, after the developer's code is checked in and before the binary is assembled. Compromise the distribution server — replace the legitimate package with a modified one after signing.
Or compromise the update mechanism itself — perform a man-in-the-middle attack on the update download and deliver a different package than the one the server hosts. "Every point in this pipeline," Marcus says, "is a potential attack surface. The vendor's security posture determines whether those surfaces are defended."
Scene 3: Supply Chain Attack at Scale
Marcus pulls up a case study. In 2020, attackers compromised the build system of a widely-used IT management platform. The attackers inserted a backdoor — named SUNBURST — into the platform's legitimate update package. The package was signed with the vendor's valid code-signing certificate. It passed all integrity checks. It was distributed through the vendor's normal update infrastructure to approximately 18,000 organizations. Recipients included government agencies, Fortune 500 companies, and security firms.
The backdoor lay dormant for up to two weeks after installation before activating, to evade detection by sandbox analysis tools that run samples for only a few minutes. Once active, it established a covert communication channel to attacker-controlled infrastructure and allowed lateral movement, data exfiltration, and persistent access. "The organizations that were compromised didn't do anything wrong," Marcus says. "They installed an update from a trusted vendor, verified by a valid certificate. The trust was broken at the source — before the update ever reached them."
Scene 4: Attacking the Package Manager
Marcus explains a different attack vector: dependency confusion. Modern software projects use package managers — tools that automatically download and install software libraries the project depends on. These package managers check both private internal repositories (the organization's own packages) and public repositories (open community package registries).
"The attack," Marcus explains, "works like this. An attacker discovers the name of a private internal package — perhaps from a job posting, a leaked configuration file, or an open-source repository. They then publish a package with the same name to the public registry — but with a higher version number. When the package manager resolves dependencies, it finds both: the real private package at version 1.2, and the attacker's public package at version 2.0. The package manager chooses the higher version number. It downloads and installs the attacker's package." The target organization's build system — or even a developer's workstation — installs and executes the malicious code automatically, as part of a normal build process. No social engineering required. The package manager did exactly what it was designed to do.
Scene 5: Code Signing, Hashing, and SBOM
A team member asks: "What can we do about this?" Marcus lists the defenses. First, code signing — every software package should be digitally signed by the vendor using a private key. The recipient verifies the signature using the vendor's public key. If the signature is invalid or the certificate is untrusted, the update is rejected. But Marcus adds the caveat: "Code signing only works if the attacker didn't compromise the signing process. If the attacker had access to the vendor's build system, they may have had access to the signing key — and the signature will be valid."
Second, hash verification — before installing, compare the hash of the downloaded package against the hash published by the vendor on a separate channel. Third, SBOM (Software Bill of Materials) — a detailed inventory of every component, library, and dependency in a software product. With an SBOM, when a compromised component is identified, organizations can immediately determine whether it is present in their environment. Fourth: pin update server addresses and validate TLS certificates to prevent man-in-the-middle attacks on the download channel itself.
Scene 6: The Trust Problem
Marcus concludes. "What makes malicious updates so dangerous is that they exploit trust that is both legitimate and necessary. You cannot stop updating software — unpatched systems are vulnerable. You cannot stop trusting vendors — your entire IT operation depends on vendor software. The attacker found the place where your defenses assume goodwill exists, and they put something there." He explains the consequences: because the malicious update is installed by the legitimate update mechanism, it bypasses endpoint detection systems that are looking for suspicious file drops or unusual execution paths. The payload arrives as a trusted process, signed with a legitimate certificate, running in the context of a legitimate application. Traditional perimeter and endpoint defenses are not designed to detect this.
"The lesson is not to distrust all updates," Marcus says. "The lesson is to verify that trust — with signatures, with hashes, with SBOMs — and to monitor for the behavior that malicious updates exhibit once installed. The delivery was clean. The behavior afterward will not be."