Malicious Updates — Glossary

A software package that appears to originate from a legitimate vendor and is delivered through normal update mechanisms, but contains attacker-inserted code. The recipient installs it willingly, believing it is a routine software improvement or security patch. Malicious updates are particularly dangerous because they exploit the trusted update channel — bypassing network perimeter defenses and endpoint detection tools that are not designed to treat vendor-signed update packages as threats.

An attack that targets a vendor, supplier, or third party in the software or hardware delivery chain rather than attacking the end target directly. Instead of breaching the target organization's network, the attacker compromises a component upstream — a software vendor's build system, a hardware manufacturer's firmware, a library used by many applications — and uses that compromise to reach all downstream recipients. Supply chain attacks are highly scalable: one upstream compromise can affect thousands of organizations simultaneously.

The practice of applying a digital signature to a software package using the developer's or vendor's private key. Recipients verify the signature using the vendor's public key and a trusted certificate. A valid signature proves two things: the package was created by the key holder (authenticity), and the package has not been modified since signing (integrity). Code signing is the primary defense against update tampering — but it only protects the integrity of the package after signing. If an attacker compromises the build system before signing occurs, the malicious code will be signed along with the legitimate code.

Comparing the cryptographic hash of a downloaded software package against a reference hash published by the vendor through a separate, trusted channel. If the hashes match, the package has not been modified in transit. If they differ, the package has been tampered with and should not be installed. Hash verification catches tampering that occurs after the package is published — such as a man-in-the-middle substitution or a compromised distribution server — but cannot detect malicious code that was present in the package before hashing.

An attack that exploits package manager resolution logic by publishing a malicious package to a public registry under the same name as an organization's private internal package, with a higher version number. When the package manager resolves dependencies, it finds both the real private package and the attacker's public package. Because package managers typically prefer the highest version number from any available source, they automatically download and install the attacker's public package instead of the legitimate private one. No user interaction or social engineering is required beyond the initial publication.

A structured, machine-readable inventory of all components, libraries, and dependencies included in a software product — including their versions, origins, and known vulnerabilities. An SBOM allows organizations to determine exactly which components are present in their software and to cross-reference those components against known compromised or vulnerable libraries. When a supply chain compromise is disclosed, organizations with SBOMs can immediately identify whether they are affected without manually inspecting every application.

Intercepting the communication between a client and an update server in order to substitute a malicious package for the legitimate one. This can be achieved through DNS hijacking (redirecting the update server hostname to an attacker-controlled server), man-in-the-middle attacks on unencrypted update channels, or BGP hijacking (rerouting network traffic at the routing layer). Mitigation requires encrypted update channels (HTTPS/TLS) with certificate validation and, for high-security contexts, certificate pinning to prevent substitution with attacker-controlled certificates.

A deliberate delay programmed into malicious update payloads between installation and activation. The SolarWinds SUNBURST backdoor lay dormant for up to two weeks after installation before establishing its command-and-control channel. The purpose is to evade sandbox analysis tools, which typically run samples for only a few minutes. A payload that shows no suspicious behaviour during sandbox analysis will be cleared as safe — even if it is not. Dormancy also separates the installation event (the update) from the malicious behaviour in time, making forensic attribution harder.