The DLL was named MpClient.dll, the same name Windows uses for a core Microsoft Defender component. Except this one wasn’t written in C++ like the real thing. It was compiled in Go, dropped alongside a legitimate signed executable, and sideloaded so that when the trusted binary launched, it quietly pulled in the fake library instead of the real one. That’s the opening move in a Vidar Stealer campaign that Unit 42 researchers just picked apart, and it’s a useful case study in how far commodity malware operators will go to stay under the radar. If you work in cybersecurity and think DLL sideloading is old news, this campaign is a reminder that “old” doesn’t mean “solved.”

What makes this campaign worth your attention isn’t Vidar itself, it’s a mature, well-documented infostealer that’s been around for years. It’s the delivery chain wrapped around it. The attackers combined a loader-as-a-service framework with a homemade DLL sideloading trick and a file-bloating technique, stacking three distinct evasion layers on top of a payload that ultimately drops both Vidar and an XMRig cryptominer. That combination hasn’t been seen together before, and it tells you something about where the loader-as-a-service market is heading: toward modular kits that any affiliate can rent and customize.

What Investigators Found: A Go-Compiled Fake DLL Doing the Sideloading

The technique itself is DLL sideloading, a technique defenders have known about for over a decade. A legitimate, signed application is placed on disk next to a malicious DLL that shares the name of a library the application expects to load. Windows’ library search order does the rest, loading the attacker’s file instead of the real one. What’s new here is the choice to compile the malicious DLL in Go rather than a more traditional language. Go binaries are statically linked, bulky, and don’t look like typical shellcode loaders to a lot of static analysis tooling that was tuned on years of C and C++ samples. That mismatch between what analysts expect malware to look like and what it actually looks like is exactly the gap this campaign is built to exploit.

Once loaded, the fake MpClient.dll acts as a stager, pulling down the next component in the chain and setting up persistence before Vidar or the miner ever executes. It’s a small piece of the puzzle, but it’s the piece that gets past the front door.

Why Code-Signing Abuse Still Works in a Post-Zero-Trust World

The campaign also leans on abused code signing, using signed binaries as the trusted anchor that the sideloaded DLL rides in on. This isn’t forged signatures or stolen private keys in the dramatic sense; it’s often signed installers or utilities that get repurposed, or certificates obtained through shell companies that pass just enough scrutiny to get issued. Either way, the effect is the same: security tools that give signed binaries a pass, or that weight signature validity heavily in their scoring, wave the whole chain through.

This is the recurring failure mode across a lot of recent campaigns, and it’s worth internalizing as a general principle rather than a one-off detail. A valid signature tells you who vouched for a file at a point in time. It does not tell you what that file does today, and it says nothing about the DLL sitting next to it that the signed binary will happily load. Any threat detection strategy that stops evaluating a binary once it sees a green checkmark is leaving a door open.

File Inflation: Padding Malware Past Sandbox Limits

The third layer is file inflation, padding the payload with junk data until it exceeds the size ceilings that a lot of sandboxes and automated scanning pipelines enforce for performance reasons. Many detonation environments cap the file size they’ll analyze, both to control compute costs and to keep turnaround times fast. Attackers know this, and bloating a payload past that threshold means it either skips deep analysis entirely or gets deprioritized in a queue. It’s a crude technique, but crude techniques that work don’t need to be clever.

Stack all three layers together, Go-based sideloading that dodges signature-based static analysis, signed binaries that suppress trust scoring, and inflated files that dodge sandbox limits, and you get a delivery chain that’s specifically engineered around the assumptions built into a lot of automated defenses. None of the three techniques is new. The combination is.

Response Actions: Hardening Against Loader-as-a-Service Campaigns

None of this requires exotic countermeasures, but it does require treating detection as a layered problem rather than a checklist. Security hardening against this style of attack means assuming that any single control, signature validation, sandbox size limits, static file scanning, can be routed around, and building defense in depth so that no one bypass is fatal.

• Monitor for unsigned or mismatched DLLs loading from application directories where only signed libraries should reside, not just at install time but continuously.
• Flag anomalous file sizes in your sandbox pipeline instead of silently skipping oversized samples; a payload padded specifically to dodge your size cap is itself a signal.
• Don’t let a valid code signature suppress behavioral alerts; correlate signed-binary execution with what it actually does post-launch, including child processes and network calls.
• Audit library search order and application directories on endpoints for planted files that predate legitimate installers, a classic sideloading indicator.
• Feed loader-stage indicators, not just final-payload hashes, into your threat detection rules; the Vidar binary changes far more often than the loader mechanics do.

On the incident response side, treat any confirmed sideloading detection as a full compromise assessment trigger, not an isolated cleanup. If a Go-compiled fake MpClient.dll made it onto one endpoint, check for the same loader-as-a-service infrastructure reaching out from others. These kits are built for reuse across victims, and firewall egress logs pointed at the loader’s callback infrastructure are often the fastest way to find sibling infections before they escalate. Cryptomining payloads like the XMRig miner riding alongside Vidar in this campaign are also a useful tell: unexplained CPU spikes on endpoints are sometimes the loudest signal you’ll get that something quieter, like a credential stealer, is also running.

Sources

• Vidar Stealer Unmasked: Code Signing Abuse, Go Loaders and File Inflation