DLL Sideloading Attacks: How HollowFrame Turned a Trusted Python Binary Into a Backdoor

DLL sideloading attacks keep turning up in intrusion reports. There is a simple reason for that. They abuse a design decision in Windows, not a bug. A new case from Blackpoint Cyber’s Adversary Pursuit Group shows how far the trick can be stretched. It involves a fresh loader called HollowFrame and a backdoor family called Matryoshka. Together they show what happens when an attacker takes real time to build around an old technique.

The target was a law firm. Two endpoints were compromised. But the interesting part, for anyone testing or defending a Windows environment, is not who got hit. It is how a completely legitimate program ended up running attacker code.

What DLL sideloading attacks actually do

Windows programs load supporting code from DLL files. They trust whichever file has the right name and sits in the expected folder. They do not check who signed it or where it came from. Now picture a legitimate, signed program that looks for a DLL by name, not by a verified path. An attacker just has to drop a malicious DLL into that same folder. The program loads it without complaint. It then runs under the trusted program’s own identity.

That last part matters. Security tools often give more trust to activity spawned by well-known, signed binaries. A DLL loaded by python.exe looks, on the surface, like ordinary Python activity.

How HollowFrame put it into practice

The chain started with a phishing email. It pointed to an encrypted archive on Mega. Inside was a shortcut file disguised as case documents. Opening it ran obfuscated PowerShell. That script added Defender exclusions for a staging folder and for python.exe, then pulled down a genuine, embeddable copy of Python.

Next came the sideload. The legitimate python.exe was placed next to a malicious file called python311.dll. Python looks for that library by name in its own folder first. So it loaded the attacker’s file instead of the real one. That rogue DLL was HollowFrame itself, a modular Go-based loader. It decrypts further stages and drops a native executable. That executable hands off to a second trusted-looking process, which sideloads the final backdoor, Matryoshka.

Matryoshka then gave the attacker two channels to pick from. One talks over plain HTTP for direct commands. The other hides inside a private GitHub repository. It gets polled the way a normal update check would look. Each compromised machine gets its own folder inside that repository. That keeps tasking organised without standing out.

It is worth being precise about why the sideload worked. The same conditions turn up in plenty of other environments. Python’s embeddable version checks its own folder for supporting files first, by name, before looking anywhere else. Placing python311.dll next to python.exe in a writable staging folder was enough. There was no registry change. There was no new service. A file integrity check that only watches system folders would miss this entirely.

Why this slips past so many defences

Three things make this style of DLL sideloading attack work. Each one is worth testing for directly, rather than assuming your tooling already handles it.

First, the exclusions. Before the malicious DLL ever loads, the attacker disables the control most likely to catch it. Nobody watches for unauthorised Defender exclusion changes, so that step goes unnoticed. Second, inherited trust. A DLL loaded by python.exe, or by any signed utility, does not raise much suspicion. That is true even though the code running is entirely attacker-controlled. Third, deliberate staging. The chain is split across several files and processes. No single artefact tells the full story to a lone alert.

What to actually check

• Alert on new Defender (or EDR) exclusion rules that were not created through change management, especially ones scoped to a single folder or executable.
• Hunt for signed interpreters and utilities, Python included, loading DLLs from user-writable locations such as temp, downloads or appdata folders instead of their own install directory.
• Baseline outbound connections to code-hosting APIs like GitHub from ordinary desktop machines. Regular staff have little reason to poll them directly.
• In your next internal or red team engagement, ask explicitly whether sideloading through commonly whitelisted binaries is in scope. Many standard test plans still focus only on network-level findings.
• Review scheduled tasks, WMI event subscriptions and Startup folder entries on any machine that opened a suspicious attachment. These were the exact persistence routes used here.

None of these checks are exotic. They just need someone to look for DLL sideloading attacks on purpose, before an attacker builds the next chain around the same blind spot.

It is also worth asking this of any monitoring service you already pay for. Would it flag a signed interpreter loading a DLL from an unusual folder? Or would it wave the connection through because the parent process looked trustworthy? That question is cheap to ask. It is often uncomfortable to answer. That is exactly why it is worth asking before an incident forces the conversation.