Diagnosing and Removing a Persistent Windows Trojan

A family friend — I'll call her by her real first name, Elizabeth, since she's comfortable with that — messaged me about a Windows 11 laptop acting strangely: a security alert she didn't fully understand, a browser that stopped opening, and a growing list of things that felt suspicious but weren't clearly connected. This is a walkthrough of how that got diagnosed properly: what turned out to be a real, multi-stage infection, and what turned out to be nothing at all.

The point of writing this up isn't the malware itself — the specific trojan family isn't rare. It's the method: verify before you conclude, treat every claim (including ones from other AI tools) as something to check, and resist the pull to connect unrelated symptoms into one dramatic story when the boring, separate explanations fit the evidence better.

The presenting symptoms

Windows Security showed two "Threat quarantined" events and, more importantly, two entries marked Remediation incomplete — Abandoned: Windows Defender had found something malicious but hadn't finished removing it. Around the same time, a browser popup appeared referencing a missing file, and Elizabeth had separately noticed some odd account activity that felt connected, but wasn't confirmed to be.

Diagram: how the infection actually worked

Windows Defender's detail view named the threat and its file path directly: Trojan:Win32/Posilod.CA!cl at C:\ProgramData\OpenJDM\jli.dll. The folder name is the tell — "OpenJDM" mimics a legitimate Java Development Kit install, but it's not a real, standard Java folder. This is a known technique called DLL side-loading: drop a malicious file with the exact name a legitimate program expects, next to (or instead of) a fake copy of that legitimate program, so the malicious file gets loaded automatically.

Once Defender quarantined jli.dll, the file was gone — but the thing trying to launch it wasn't. That's why a "jstat.exe – jli.dll was not found" error kept appearing on browser startup: a leftover, orphaned startup entry was still trying to run a file that no longer existed. Removing the visible popup meant finding and deleting that entry, not just the DLL Defender had already handled.

Standard remediation sequence

Before touching anything else, the base cleanup followed Microsoft's own layered approach rather than any single tool:

1. Microsoft Defender Offline scan — reboots into a minimal pre-Windows environment so nothing already running can hide from the scanner.
2. Microsoft Safety Scanner — an independent, portable second-opinion engine from Microsoft, run alongside Defender rather than replacing it.
3. Malwarebytes (free) — an on-demand cleanup pass specifically to catch anything the first two missed.

Reading the machine directly: parsing Autoruns by hand

Sysinternals Autoruns lists every program configured to start automatically — Run keys, scheduled tasks, services, browser extensions, all of it. Elizabeth exported her full Autoruns snapshot as a .arn file and sent it over. The catch: .arn isn't plain text. It's an OLE compound document — the same binary container format used by old .doc files — with a separate internal stream for every field of every entry.

Rather than eyeballing it in the Autoruns UI, I instructed Claude AI to write a short script to parse it directly:

That gave a clean, searchable list of all 1,843 entries — confirming OpenJDM and jli.dll were already gone, and surfacing three scheduled tasks Defender had never flagged at all:

This pattern — a random hex-named folder inside ProgramData, pythonw.exe as the launcher (it runs without a visible console window), and unsettling, deliberately memorable task names — matches documented Python-based loader techniques where the payload self-deletes after running once, leaving only the scheduled-task registration behind. "File not found" doesn't mean harmless; it can mean the malware already did its job and cleaned up after itself.

Removing these required opening Task Scheduler directly and deleting each task by name — no antivirus scan alone was going to catch registration entries pointing at files that no longer existed.

Separating signal from noise

Once something genuinely malicious is confirmed, it's tempting to treat every subsequent odd thing as part of the same story. Three things came up that looked suspicious on the surface but checked out as unrelated and benign once verified individually:

The hardware red herring

The most instructive false lead: using Windows Magnifier (Win + Plus) to zoom in reliably closed every open Chrome window. Given everything else happening on the machine, the obvious hypothesis was "part of the infection." It wasn't.

The laptop's Autoruns export also showed Intel Arc integrated graphics components. Intel's own community forum has an active, documented bug: the Arc driver can crash during Windows-key and focus-transition events, triggering a full Desktop Window Manager reset — which takes GPU-accelerated applications down with it. Chrome is heavily GPU-accelerated. Magnifier's full-screen mode is precisely the kind of Windows-key-driven compositor transition the bug report describes.

Outcome

End state: the original DLL side-load was already quarantined by Defender; the three orphaned scheduled tasks were located by parsing the raw Autoruns data and removed manually from Task Scheduler; three unrelated "suspicious" observations were checked and ruled out individually rather than folded into the malware narrative; and a genuinely separate hardware bug was correctly isolated from the security investigation and pointed at a driver update instead of another malware scan.

Key takeaways

Appendix: tools & terminology referenced above

A quick-reference glossary and comparison for readers who want to understand what each tool in this case study actually is, and how the surrounding options in that category stack up.

What each Microsoft/security tool actually is

Browser comparison: privacy and download safety

VPN comparison: what actually hides an IP address

A browser VPN, however good, only wraps traffic from that one browser. Everything below is a real, device-wide comparison for anyone whose goal is genuinely hiding their IP address across every app, not just one browser tab.