A recent attack campaign demonstrated a troubling reality for defenders: legitimate code signatures and trusted distribution channels are now primary attack vectors. Researchers uncovered a fake LastPass Authenticator installer hosted on GitHub that deployed a Windows kernel driver signed by Microsoft itself to disable antivirus and endpoint detection and response (EDR) software before executing a password stealer.
The Signature Paradox
The driver in question was signed through Microsoft's hardware compatibility programme, giving it the cryptographic legitimacy that operating systems and security tools trust by default. When researchers submitted it to VirusTotal immediately after discovery, it returned zero detections across major antivirus vendors. This is not a failure of individual vendors but a structural problem: code signatures verify authenticity, not intent. A signature confirms that code came from a known entity and hasn't been tampered with after signing. It says nothing about whether that entity's code will harm your system.
Attackers have recognised this asymmetry. By obtaining legitimate signatures—whether through compromised developer accounts, deliberate abuse of trusted programmes, or social engineering—they gain a powerful shield against security tools that are trained to be cautious with unsigned code. The driver in this case could load into kernel space with minimal friction because its signature satisfied the trust requirements of the operating system itself.
GitHub as an Infection Vector
Distribution matters as much as the code itself. The fake LastPass installer was hosted on GitHub, a platform where millions of developers pull code daily. An attacker registering a plausible repository name and publishing a single malicious release can reach thousands of users with minimal friction. GitHub's abuse detection systems, whilst improving, rely partly on user reports—and many victims won't realise they've been compromised until a credential stealer has already extracted their secrets.
For infrastructure teams pulling dependencies or tools from public repositories, this represents a material risk. A single compromised or impersonated project can inject malware into your build pipeline or workstations. The attack doesn't require the repository owner to be negligent; it requires only that an attacker create a convincing enough fake.
Kernel-Level Privilege Escalation
The use of a kernel driver elevates this beyond typical malware. Antivirus and EDR tools operate partly in user space and partly in kernel space. A signed kernel driver can disable or unload security callbacks before they see malicious activity. This is why kernel-level access is so prized by attackers: it allows them to work below the abstraction layer where user-mode security operates.
Organisations relying solely on EDR as a containment mechanism should recognise the gap. EDR is valuable, but it is not impenetrable. If an attacker can load unsigned code with kernel privileges—or, worse, signed code that Microsoft trusts—many EDR solutions become ineffective. Defence-in-depth is not optional; it is mandatory.
What This Means for Your Infrastructure
Several practical implications follow. First, code signing is a necessary but insufficient control. Organisations should implement driver signing requirements and code integrity checks, but also maintain whitelisting of known-good binaries and restrict kernel driver loading to approved sources wherever possible. Windows features like Secure Boot and Hypervisor-Protected Code Integrity (HVCI) add friction to kernel-level attacks, though they are not universally enabled.
Second, source verification matters. If you pull tools from public repositories, audit the repository itself: check the creation date, the contributor history, the issue and pull request activity. Impersonated projects often lack the incidental detail of legitimate ones. Consider mirroring critical dependencies internally rather than pulling from the public source during builds.
Third, assume compromise at the endpoint level. Infrastructure teams should operate under a security model where user machines are not fully trusted. This means using hardware security tokens instead of software-based credential storage, implementing network segmentation so that compromised workstations cannot freely pivot to infrastructure, and monitoring for unusual access patterns even from authenticated users.
The Larger Pattern
This incident fits a broader trend: attackers are moving upstream in the supply chain, away from direct exploitation of vulnerabilities and towards manipulation of trust relationships. Each link in the chain—code signing, package repositories, distribution platforms—was designed to build confidence. Attackers now use those confidence signals as camouflage.
The only reliable defence is to treat all code, signed or not, with appropriate suspicion. Run it in sandboxed or isolated environments first. Monitor its behaviour. Assume it could be malicious. This is not paranoia; it is the only posture that works when the trust infrastructure itself has become a weapon.
