UAC-0099 Weaponizes Notepad++ and WinRAR Plugins to Deliver Malware

Since mid-2026, defenders have been tracking a shift in how the threat group UAC-0099 operates. Instead of leaning purely on custom-built malware, the group is increasingly using a living-off-the-land approach: hijacking popular, legitimate software like Notepad++ and WinRAR to smuggle malicious code past security defenses. For the broader technique this fits into, see our guide to living-off-the-land phishing attacks.

This isn’t just a story about a text editor and an archiving tool, but a case study in a much larger risk: how software plugins, extensions, and dependencies expand your attack surface, no matter how trusted the host application is.

The Infection Chain

The attack unfolds in five stages, each one designed to look unremarkable on its own.

1. The lure and initial payload. It starts with a phishing email containing an embedded image. Clicking it routes the victim through a URL shortener to a legitimate file-sharing service, which serves a ZIP archive with a deliberately boring name, something like “Annexes to the order.zip.” Inside is a malicious Visual Basic Script. The attackers pad the filename with whitespace, naming it something like “Report.pdf .vbs,” so it displays as a harmless PDF at a glance. Double-clicking opens a decoy PDF while quietly dropping a second archive in the background.

2. DLL sideloading via plugins. That second archive contains a complete, legitimate copy of Notepad++, bundled with a malicious plugin disguised as a real one. The script extracts everything and launches the real notepad++.exe. Because Notepad++ automatically loads third-party plugins sitting in its directory, it executes the malicious DLL without complaint. Security software sees a trusted, digitally signed application running. It has no visibility into what’s happening underneath it.

3. Establishing persistence. The malicious DLL decrypts a password-protected archive dropped earlier in the chain. To survive a reboot, it copies a standard Windows utility, renames it, and creates a scheduled task that re-runs the next stage every three minutes.

4. Loading and evasion. The scheduled task triggers a loader whose only job is to pull the final backdoor into memory. If a security researcher runs it without the exact command-line arguments the malware expects, it deliberately floods CPU and RAM to stall analysis, a booby trap built specifically to waste an analyst’s time.

5. The final backdoor. The last payload establishes command-and-control communication and waits for instructions. To unpack additional tools it needs, it relies on WinRAR being present on the machine. If it isn’t, the malware reaches out to Dropbox, downloads a legitimate copy of WinRAR, and uses it to extract further modules. Even the tool used to finish the job is borrowed trust.

Why Extensibility Is the Real Attack Surface

The UAC-0099 campaign is a clean example of a pattern that shows up everywhere software allows third-party code to run inside a trusted process. A corporate text editor, a browser, a code library, a video game, it doesn’t matter which. Letting unvetted code execute inside something your security tools already trust is inherently risky.

This isn’t limited to desktop plugins, either. Custom community maps for the game Mecha Chameleon were recently found weaponized in a similar spirit: a map embedded a malicious batch file that reached out to a command-and-control server and pulled down a PowerShell dropper, compromising the player’s system the moment the map loaded.

The same underlying mechanics show up across very different ecosystems. We’ve covered the browser-extension version of this problem in depth here, the open-source package version here, and a WordPress-specific case here. Different host applications, same underlying trust exploit: whatever you plug in gets the same trust level as the application it’s plugged into.

Defensive Strategies

Defending against plugin-based, trust-borrowing attacks like this one comes down to a few concrete practices.

Pin by hash, not just version. In CI/CD pipelines and package management generally, a version tag can be overwritten or poisoned. A cryptographic hash guarantees the file you’re pulling is mathematically identical to the one you originally vetted.

Deploy supply chain scanners. Software Composition Analysis tools continuously check your dependency tree for known vulnerabilities and poisoned packages hidden in open-source components.

Treat every plugin as untrusted by default. Extensions, add-ons, and mods should all be evaluated as potentially hostile code, not convenience features. If a plugin isn’t strictly necessary for the job, it doesn’t belong on a work machine.

Separate personal and corporate devices. Keep hobbies off business hardware. Gaming, mod testing, and personal crypto activity belong on a separate machine from the one that holds corporate access.

Attackers are counting on the fact that people trust familiar logos and popular software. Turning trusted tools into delivery mechanisms lets them bypass technical controls through simple habit. Every component that enters your environment, no matter how small or how well-known its name, is worth validating.

This breakdown is based on threat intelligence from CERT-UA (Computer Emergency Response Team of Ukraine), who published the original technical advisory.

Worried about which trusted tools in your environment could already be compromised? See how PhishFort helps detect supply chain and living-off-the-land threats before they reach your users →