Every managing partner I talk to says some version of the same thing when a security topic comes up: we have antivirus, IT keeps things patched, we’re covered. A story out of April 2026 breaks that assumption in about four sentences.
A fake Windows 11 update started circulating that looked close enough to the real thing to fool almost anyone, including the antivirus software sitting on your firm’s machines. It wasn’t built to slow you down. It was built to steal passwords.
It’s not a sloppy fake
According to security firm Malwarebytes, the fake update lived on a typosquatted domain, microsoft-update[.]support, styled to look like an official Microsoft page. It offered a cumulative update for Windows 11 24H2, complete with a believable KB article number and a large blue download button. Click it, and the installer that runs is not a Windows patch. It’s malware.
Older versions of this scam were easy to catch. Bad grammar, a slightly wrong logo, a domain that didn’t quite match. This one wasn’t that. The malicious file was built using WiX Toolset, a legitimate open source tool that real software developers use every day. The installer’s author field even reads Microsoft. Its title reads Installation Database.
Here’s the part that should get a managing partner’s attention. When Malwarebytes ran the file through VirusTotal, a service that checks a file against dozens of antivirus engines at once, it came back with zero detections across 69 of them. The malicious code sits hidden inside an Electron shell, a common framework used to build legitimate desktop apps. Antivirus tools check the outer shell, see a familiar framework, and let it through. They never look at what’s packed inside.
Think of it like the front desk checking a visitor’s ID before letting them into the building. This one showed up with a real ID borrowed from a framework everyone recognizes, carrying something dangerous in a bag nobody thought to open.
What a stolen password opens at a firm
A password stolen from a home user is bad. A password stolen from someone at your firm is worse, because it’s rarely just theirs. It might open Clio, the firm’s email, a client portal, or the bank login tied to the trust account.
That last one is the reason this matters more for a firm than for most businesses. Client confidentiality is not a best practice you get to when you have time. It’s the duty behind ABA Model Rule 1.6(c), which requires reasonable efforts to prevent unauthorized access to information relating to a client’s representation. California firms carry a comparable duty through Business and Professions Code section 6068(e), Rule 1.1’s competence requirement, and Formal Opinion 2010-179, structured differently but landing on the same expectation: you took reasonable steps.
Reasonable efforts. Not perfection.
But reasonable gets harder to argue after a stolen password leads to a trust account withdrawal, a client email thread landing somewhere it shouldn’t, or a malpractice claim built on the fact that a known, well documented attack technique got past the firm’s defenses because nobody closed an obvious gap. Cyber insurance renewals are already asking about this. If your firm’s answer to does every account require multi-factor authentication is no, this is the story that makes the underwriter’s question feel less theoretical.
What to do before the next one shows up
Keep updates inside Windows. The safest way to check for and install updates is through the built in Settings app, not a link in an email or a page from a search result. If someone genuinely needs to download something manually, send them to support.microsoft.com directly and nowhere else.
Tighten who can install software on firm machines in the first place. If an associate or paralegal doesn’t have local admin rights, a fake installer like this one has nowhere to run even if someone clicks it. That’s a bigger lever than any single antivirus update, and it closes the same gap that shows up every time a departing employee’s access doesn’t get revoked on schedule.
Treat MFA as the backstop, not the extra step. A trust account withdrawal already requires two signatures, because one person’s mistake, or one person’s compromised credentials, shouldn’t be enough to move client funds on its own. Login to firm systems deserves the same principle. If a stolen password alone isn’t enough to get into an account, an attack built entirely to harvest that password stops being useful to whoever is running it.
Back to where this started. Could you tell an insurer, a client, or opposing counsel exactly which systems a single stolen password would open at your firm today? If the honest answer feels closer to not sure than to yes, that’s the gap worth closing before a regulator, an insurer, or a malpractice claim forces the question. We help firms map that access, tighten who can install what, and put MFA where it actually matters, and it’s easier to do now than after one of those pressures makes it urgent.