Signed Binary DLL Side-Loading Detection for SMB Security Teams

Here is a sentence that should bother every Windows administrator a little: the most trusted file on a compromised laptop is often the one doing the attacker's work. Signed binary DLL side-loading is the technique behind that sentence, and it has quietly become the default delivery method for nation-state operators and ransomware crews alike. The executable carries a perfectly valid signature from a real security vendor or hardware maker. The DLL sitting next to it in the same folder does not. Windows loads both, the process tree looks boring, and the malicious code runs wearing somebody else's reputation.

This spring the Iranian group tracked as MuddyWater pushed that idea about as far as it goes, with campaigns across nine countries that dropped legitimately signed SentinelOne and Fortemedia binaries next to malicious libraries and let the loader do the rest. This week the Lazarus Group showed up abusing CrossWeb EX, a South Korean browser security plugin, in a campaign researchers are calling FlashHole. Different operators, different continents, same basic bet. They are betting that your detection stack trusts the signature more than it watches the behavior. For a lot of small and mid-sized businesses in DFW and everywhere else, that is a winning bet. It does not have to be.

Why signed binary DLL side-loading works on almost every Windows endpoint

The mechanics are not exotic, which is part of the problem. When a Windows program asks for a library by name rather than by full path, the loader goes looking for it in a defined order, and the directory the application itself lives in sits near the top of that order. Microsoft documents the behavior plainly in its guidance on dynamic-link library search order, and it exists for good reasons. Applications ship with their own private copies of libraries, and Windows needs to find them without every developer hard-coding a path.

An attacker reads that same documentation and sees an opportunity. Find a signed executable that imports a library by name, ideally one that does not verify the signature of what it loads. Copy that executable into a folder the attacker controls, such as somewhere under a user's AppData or ProgramData directory. Drop a malicious DLL alongside it with the expected filename and the expected exported functions. Launch the executable. The loader checks the application directory first, finds the attacker's file, and maps it into a process that every reputation engine on the planet recognizes as legitimate.

MITRE ATT&CK files this under Hijack Execution Flow (T1574), with DLL side-loading as one of its library sub-techniques, and the reason it keeps appearing in threat reports is that it solves three attacker problems at once. It gets code execution without dropping an unsigned executable that would trip application reputation checks. It inherits whatever trust, firewall exceptions, and allowlist entries the legitimate binary already enjoys. And it often provides persistence for free, because the attacker simply registers the signed executable as a scheduled task or a Run key, and the defender reviewing autoruns sees a vendor name they recognize and moves on.

The supply of vulnerable executables is enormous. The community project HijackLibs, maintained by researcher Wietze Beukema, catalogs hundreds of signed binaries from Microsoft and third-party vendors that will happily load a library from their own directory. Some of them are security tools. Some are printer utilities, audio drivers, update helpers, and the kind of bundled software that ships preinstalled on a laptop from a big box store. Attackers do not need a zero-day for any of this. They need a file manager and a little patience.

The MuddyWater playbook and the long lineage behind it

MuddyWater is not new to this. The joint CISA, FBI, NSA, and UK NCSC advisory AA22-055A from February 2022 described the group's PowGoop loader, which masqueraded as a Google Update component and relied on a legitimate executable loading a malicious Goopdate.dll. The 2026 campaigns are the same idea with better taste in donor binaries. Choosing a SentinelOne-signed file is a deliberate bit of trolling, because a defender who sees an endpoint security vendor's executable running on a host is primed to assume it belongs there. Choosing a Fortemedia audio component is the quieter version of the same trick, since audio driver helpers are exactly the background noise nobody audits.

The lineage runs much deeper than one Iranian group. PlugX, the remote access trojan that has passed through the hands of multiple China-nexus operators for well over a decade, practically made side-loading its signature move, pairing signed antivirus and utility executables with malicious libraries across countless intrusions. In 2022, SentinelOne researchers documented LockBit affiliates abusing MpCmdRun.exe, the Microsoft Defender command-line utility, to side-load a malicious mpclient.dll that decrypted and launched Cobalt Strike. That one deserves a moment of appreciation for the sheer nerve involved, because it turned the operating system's own antivirus tooling into the loader.

The 2023 3CX supply chain compromise showed the technique from another angle. The trojanized desktop application loaded a tampered ffmpeg.dll and a d3dcompiler_47.dll carrying an encrypted payload, and because the installer itself came from the vendor, every signature check along the way passed. That incident is a useful reminder that side-loading is not only something an attacker does after landing on a host. It can be baked into what you install on purpose.

The Lazarus activity disclosed this week fits the same pattern from the other side of the world. South Korean organizations have long depended on browser security plugins for banking and government portals, which makes those components widely deployed, widely trusted, and rarely inventoried. Whether the specific abuse is side-loading, a vulnerable update channel, or both, the lesson for defenders is the same. Software that exists to provide security is still software, and if it can be convinced to load or launch attacker code, it becomes the best camouflage available.

Why antivirus and EDR keep letting the loader through

It would be comforting to believe a modern endpoint detection and response product catches this every time. Sometimes it does. Often it catches the second or third stage rather than the side-load itself, and occasionally it catches nothing at all until the attacker does something loud. Understanding why helps you decide where to spend effort.

Most endpoint tools weight signer reputation heavily, because without that weighting they would drown customers in false positives. A signed executable from a known vendor starting up is not, by itself, interesting. The malicious DLL is the interesting part, but it is loaded into a trusted process, frequently packed or encrypted, and often does nothing suspicious until it decrypts a second payload in memory. By the time the behavior gets loud enough to score as malicious, the attacker may have already established a scheduled task, harvested browser credentials, or opened a command channel over HTTPS to infrastructure that looks like a content delivery network.

There is also a tuning problem that SMB environments make worse. Every exclusion a busy administrator adds to quiet a noisy line of business application is a hole shaped exactly like a trusted path. If the endpoint policy excludes an entire vendor directory because the accounting software kept tripping alerts in 2024, an attacker who side-loads into that directory inherits the exclusion. I have reviewed policies in Plano and Frisco environments where the exclusion list was longer than the detection rule set, and nobody in the building could explain half of the entries.

None of this means endpoint protection is useless. It means the signature on an executable answers exactly one question, which is who built this file. It says nothing about where the file is running from, what it loaded, or whether it has any business being on the machine at all. Signed binary DLL side-loading lives entirely in those unanswered questions.

Detecting DLL side-loading with telemetry an SMB already owns

The good news is that DLL side-loading detection does not require an expensive new product. It requires asking a handful of specific questions of telemetry that most organizations either already collect or could collect this week at no licensing cost.

The single most useful signal is location. Legitimate signed executables generally live where their installers put them, under Program Files, Program Files (x86), or the Windows directory, and those locations require administrative rights to write. A vendor-signed binary executing out of a user's AppData folder, the Public profile, a temp directory, or a freshly created folder under ProgramData is worth a look every single time. When that same process loads a library that is unsigned or signed by a different publisher than the executable itself, the look becomes an investigation. A SentinelOne-signed binary running from a user profile and loading an unsigned DLL is not an edge case that needs nuanced tuning. It is a finding.

Microsoft Sysinternals Sysmon gives you the raw material for that logic for free. Event ID 1 records process creation with the image path and hashes, Event ID 7 records image loads including the signature status and signer of each loaded module, and Event ID 11 records file creation, which lets you catch the moment an executable and a DLL land in the same new directory within seconds of each other. Image load logging is noisy if you turn it on for everything, so the sensible approach is a configuration that excludes loads from protected system paths and keeps the loads from user-writable locations. Most EDR platforms expose the same data through their own hunting interfaces, and if yours does, use it there instead of running two agents.

The second useful signal is pairing. Attackers need the executable and the library to sit side by side, which usually means both get written to disk close together in time, frequently by a script host, an archive utility, or a browser download. An alert that fires when a signed executable and an unsigned DLL appear in the same non-standard folder within a short window will catch a remarkable share of commodity and nation-state side-loading alike, because the delivery step is hard to avoid.

The third signal is behavior after load. A printer helper or audio utility has a narrow and predictable profile. It should not be making outbound HTTPS connections to newly registered domains, spawning PowerShell, reading browser credential stores, or creating scheduled tasks. Baselining what your common vendor binaries normally do, even informally, makes deviations obvious. This is also where NIST SP 800-53 control SI-4 earns its keep, because system monitoring that only fires on known-bad signatures will never see a known-good process doing unknown-bad things.

Finally, protect the evidence. Sysmon logs that live only on the endpoint can be cleared by anyone who reaches administrative rights there, which is why AU-9 protection of audit information matters as much as collection. Forward the events to a log platform the endpoint identity cannot write to or delete from, and alert when a host that normally reports suddenly goes quiet. Absence of telemetry is a detection in its own right.

Controls that shrink the attack path before detection has to save you

Detection is the safety net. The better investment is making the technique harder to pull off in the first place, and the most effective control here is one that a lot of SMBs have been told is too hard for them. Application allowlisting, which NIST SP 800-53 frames under CM-7(5) and which the Australian Signals Directorate has kept near the top of its Essential Eight for years, is the control that directly addresses where code is allowed to run.

Microsoft App Control for Business, the feature formerly known as Windows Defender Application Control, can enforce policy on DLLs as well as executables. That matters, because the classic AppLocker approach leaves DLL rules disabled by default for performance reasons, and plenty of organizations that believe they have allowlisting actually have executable allowlisting with a library-shaped gap in it. Even a modest policy that blocks execution from user-writable paths closes off the most common side-loading staging locations without requiring you to catalog every application in the business. Start in audit mode, read what it would have blocked for a few weeks, and then enforce. The audit logs alone will teach you more about what runs in your environment than most asset inventories.

Asset inventory is the next lever, and CM-8 is the control that tends to fail quietly. Side-loading thrives on software nobody remembers installing. The bundled OEM utility, the abandoned conferencing client, the browser plugin a single department needed for a state portal in 2021. Every one of those is a potential donor binary or a potential victim. Removing software you do not need is the cheapest hardening available, and it shrinks the pool of signed executables an attacker can borrow from your own machines.

Local administrator rights deserve their usual scolding as well. Users without local admin cannot write to Program Files, cannot install services, and cannot add machine-wide persistence, which forces side-loading into user-writable locations where the detections described above are strongest. AC-6 least privilege does not stop the technique outright, but it pushes the attacker into the part of the file system you are watching most closely.

For the software you build or distribute yourself, the fix belongs upstream. Developers should load libraries by full path, use the SetDefaultDllDirectories and LoadLibraryEx flags that restrict search locations, and verify the signature of anything they load at runtime. If your company ships a Windows agent or utility to customers, assume an attacker will eventually test whether your signed binary makes a convenient loader, and make sure the answer is no before your logo ends up in somebody else's threat report.

What a Managed SOC should be hunting this quarter

If you have a Managed SOC or MDR provider, signed binary DLL side-loading is a fair test of whether the service is doing analysis or forwarding alerts. Ask them a few direct questions. Do they collect image load telemetry, or only process creation? Do they alert on signed executables running from user-writable paths, and how do they handle the inevitable false positives from legitimate per-user installers such as Teams or Zoom? Can they show you a hunt they ran against the MuddyWater indicators from this year, or the LockBit MpCmdRun pattern from 2022? A provider that answers with specifics is earning the invoice. A provider that answers with a marketing slide about artificial intelligence is not.

The hunt itself is straightforward to describe. Pull every instance of a signed executable running outside its expected installation path across the fleet over the last ninety days. Enrich each one with the signer of every module it loaded and every network destination it contacted. Group by executable name and hash, because the same donor binary tends to appear across multiple hosts in a campaign. Then look hard at the outliers, especially security tools, update helpers, and hardware utilities running from places their installers would never use. In my experience the first pass through that data turns up at least one thing nobody can explain, and it is usually old forgotten software rather than an active intrusion. That is still a useful result, because forgotten software is where the next intrusion goes to hide.

Correlation across identity telemetry closes the loop. Side-loading is a means to an end, and the end is usually credential theft followed by cloud access. This week's reporting on Microsoft 365 token replay attacks across dozens of organizations is a reminder that an endpoint foothold today becomes a mailbox compromise tomorrow. A SOC that can line up a suspicious image load on a laptop with an unusual token use from the same user an hour later is doing the job. A SOC that sees those as two unrelated tickets in two different consoles is not.

Turning signed binary DLL side-loading into a solved problem

Nothing about this technique requires the attacker to be brilliant. It requires them to understand how Windows finds libraries better than the defender does, and to count on the defender treating a valid signature as a verdict. Flip those two assumptions and signed binary DLL side-loading goes from invisible to one of the more detectable things an intruder can do. Location, pairing, post-load behavior, and protected logs give you the detection. Allowlisting, inventory, and least privilege shrink the attack surface underneath it. None of it is glamorous, and all of it is within reach for a fifty-person company with a part-time IT lead and a decent partner.

That combination of endpoint telemetry, identity correlation, and somebody actually looking at the results at 3 AM is the work the Managed SOC and Threat Management module inside CyberSphere was built around. It watches image load and process telemetry for exactly the signed-executable-in-the-wrong-folder pattern described above, ties those detections to identity events from Microsoft 365 and other providers so a side-loaded loader and a replayed token show up as one incident instead of two, and drops each confirmed finding into the remediation queue with the evidence and the control it maps to. Dark-web breach monitoring sits on top for the credential theft that usually follows. The platform lives at https://cybersphere.thecyberone.com/, and partners who want to run the capability under their own brand can white-label the portal. Attackers will keep borrowing other people's signatures as long as it works, so the practical goal is making sure it stops working on your machines first.

Frequently Asked Questions

How quickly does Innovation Network Design respond to a security incident?

Our SOC triages and notifies within 15 minutes with confirmed details and containment steps, rather than handing you a queued alert. Incident response retainer clients carry a 2-hour guaranteed response.

Do you only work with businesses in the Dallas-Fort Worth area?

We are based in McKinney, Texas and work on-site across Plano, Allen, Frisco and the wider DFW metroplex. Our monitoring and response operate remotely, so we also support organizations nationwide.

How do we get started?

Start with a free assessment. Contact us or call 512-518-4408 and we will review your current setup and give you clear, prioritized recommendations before you commit to anything.