Fake LastPass Installer Kills EDR With a Signed Driver

What happened

On September 17, researchers at LastPass and Delphos Labs disclosed a fake LastPass Authenticator installer being distributed through GitHub. As reported via feeds.feedburner.com, a victim who downloads and runs the installer gets a Windows kernel driver that shuts down antivirus and other security software first, clearing the way for a password stealer to run behind it.

The uncomfortable detail: the driver carries a signature issued through Microsoft's own hardware-compatibility program, and researchers reported zero detections on VirusTotal at the time of their analysis. In other words, the thing that was supposed to vouch for the code vouched for it, and the scanners everyone checks against said it was clean. If you want the full technical write-up, read the source directly rather than relying on summaries, ours included.

Why this matters for Pittsburgh SMBs

Most of the companies we work with in Pittsburgh have somewhere between 10 and 200 employees and no full-time security analyst. Your protection model is, realistically: an endpoint agent watching for bad behavior, a help desk that patches things, and staff who mostly know not to click weird links. This campaign attacks all three at once. It targets people searching for a legitimate security tool, which means the employees most likely to fall for it are the conscientious ones trying to set up MFA properly. And because it disables the endpoint agent before the payload runs, your primary detection layer may simply go quiet instead of alerting.

Think about what a password stealer actually gets in your environment. For a CPA firm in September, that's portal credentials, e-file accounts, and client financial data in the middle of extension season. For a law firm, it's document management and trust-account banking logins. For a medical practice, it's EHR access, which turns a laptop problem into a HIPAA breach analysis. For a defense supplier in the Mon Valley or out along the Parkway West, stolen credentials touching CUI systems become a DFARS 7012 incident-reporting question and a very bad conversation about your CMMC Level 2 posture. And under the FTC Safeguards Rule, financial-services firms and many accounting practices are expected to have the monitoring and access controls that would catch exactly this.

The broader lesson is about assumptions. "It was signed" and "VirusTotal was clean" are no longer adequate evidence that software is safe. Neither is "we have antivirus." What matters is whether an ordinary user can install kernel-level code on your machines at all, and whether anyone notices when your security tooling stops reporting in.

What to do about it this week

1. Confirm someone is watching for agent silence. The single most useful control against EDR-killer malware is an alert when an endpoint agent stops checking in, gets disabled, or falls behind on policy. Ask your provider, in writing, who receives that alert, how fast, and what happens overnight and on weekends. If the answer is "it's in a dashboard," that's not monitoring. Mature EDR and MDR programs treat tamper events as high-severity incidents.
2. Take away local admin rights. Installing a kernel driver requires elevation. Standard-user accounts plus a ticketed elevation process stops this class of attack cold for most staff. If removing admin rights company-wide is disruptive, start with the highest-risk groups: finance, billing, HR, and anyone touching client data or CUI.
3. Turn on Microsoft's driver blocklist and review it. Windows can block known-vulnerable and abused drivers, and Microsoft maintains that list. Verify whether the blocklist is enforced on your fleet, whether it is current, and whether this specific driver is covered. Do not assume it is, verify with your provider and with Microsoft's documentation.
4. Control where software comes from. Publish a short rule: security and authenticator software gets installed by IT, from the vendor's own site or your managed software catalog, never from a search result or a code-hosting page. Back it with application control or allow-listing where your line-of-business apps permit it. This is a natural piece of your broader acceptable-use policy alongside your AI advisory guardrails, since staff are downloading unvetted AI tools for the same well-intentioned reasons.
5. Assume credentials leaked and act accordingly. Force a password reset and revoke active sessions for any user who installed unapproved software recently. In Microsoft 365, check sign-in logs for impossible-travel and new-device activity, confirm MFA is enforced on every account including service and admin accounts, and make sure legacy authentication is off. Phishing-resistant MFA beats app-code MFA if you can get there.
6. Test your detection story, don't trust it. Run a controlled tabletop this month: an employee installs malware that disables the agent at 7 p.m. on a Friday. Walk the timeline. Who sees it? When is the client notified? Who decides whether a HIPAA or compliance reporting clock has started? Regulated firms should document the exercise, auditors ask.
7. Check your MFA rollout for the same trap. If you're mid-migration to a new authenticator app, send staff a direct install link yourself. The attackers are counting on the confusion that migrations create, and consistent patch management and software delivery removes the guesswork.

How we help

PGH Networks runs managed IT, cybersecurity, and compliance programs for Pittsburgh-area professional services, healthcare, manufacturing, and defense-contractor clients, which means tamper-alert monitoring, least-privilege enforcement, application control, and Microsoft 365 hardening are part of the day job, not an upsell. If you're in a regulated lane, our vCIO team maps these controls to the framework you actually answer to, whether that's HIPAA, SOC 2, FTC Safeguards, or CMMC. Want a straight answer on whether your endpoints would go dark quietly? Call us at 724.888.7007 or reach out through the contact form and we'll walk your environment with you.