Key Takeaways
- HollowFrame is a Go‑based loader that uses DLL side‑loading (legitimate python.exe + malicious python311.dll) and establishes persistence through a scheduled task.
- Matryoshka is a Rust‑based backdoor with two C2 variants: one communicating over HTTP to 45.158.196.184:8888, and another leveraging a private GitHub repository as a per‑host mailbox system.
- The intrusion begins with a spear‑phishing email containing an LNK file masquerading as “Case Documents,” which triggers PowerShell to download next‑stage payloads from 2.26.252.84.
- HollowFrame incorporates anti‑analysis checks (system uptime, installed memory, user‑profile file count, cursor movement) to avoid sandbox execution.
- The multi‑stage design spreads malicious logic across components, complicating detection and attribution while enabling credential theft, lateral movement, and further tooling deployment.
Infection Chain and Initial Access
The attack opens with a carefully crafted spear‑phishing message that includes a link to an encrypted archive. Inside the archive lies a Windows Shortcut (LNK) file named something benign like “Case Documents.lnk.” When the unsuspecting recipient double‑clicks the shortcut, it executes a command that launches PowerShell. This PowerShell one‑liner reaches out to a remote server at 2.26.252.84 to retrieve and execute the next stage of the payload chain. By using a seemingly innocuous LNK and relying on PowerShell—a trusted Windows component—the attackers evade many email‑gateway and endpoint heuristics that focus on executable attachments.
HollowFrame Loader Mechanics
Once the initial PowerShell stage runs, it delivers HollowFrame, a Go‑written loader framework. HollowFrame achieves execution through DLL side‑loading: it places a malicious DLL named python311.dll in the same directory as the legitimate python.exe binary. When python.exe is invoked (often by the PowerShell script), Windows loads the rogue DLL instead of the genuine one, granting the attacker code execution with the privileges of the Python process. HollowFrame is designed as a modular loader, capable of pulling in additional components as needed while performing a series of anti‑analysis checks before proceeding.
Anti‑Analysis and Evasion Techniques
To hinder dynamic analysis in sandboxes or virtual environments, HollowFrame evaluates several host characteristics. It checks the system’s uptime to ensure the machine has been running long enough to resemble a real workstation, verifies that installed memory exceeds a certain threshold, counts files in the user profile directory to gauge typical usage, and monitors cursor movement to detect human interaction. If any of these indicators suggest an automated or restricted environment, the loader aborts, thereby reducing its footprint in analysis sandboxes and increasing the chances of successful execution on genuine endpoints.
Persistence via Scheduled Task
After confirming that the host is not a sandbox, HollowFrame establishes persistence by creating a Windows Scheduled Task. The task is configured to run the python.exe binary (with the side‑loaded python311.dll) at regular intervals or at user logon, ensuring that the malicious code survives reboots and user logoffs. This mechanism is stealthy because scheduled tasks are a legitimate administrative feature, and the task can be hidden under innocuous‑sounding names, making it difficult for defenders to spot without specific monitoring of task creation events.
Deployment of Matryoshka via Second Side‑Loading Chain
HollowFrame’s payload includes an encrypted container that, once decrypted, releases a second side‑loading chain. This chain ultimately loads a DLL named version.dll, which is the Matryoshka backdoor written in Rust. The use of a second side‑loading step adds another layer of obfuscation: the initial loader appears benign, while the actual malicious functionality is only revealed after the encrypted payload is unpacked and the secondary DLL is side‑loaded via another legitimate executable (often a different system binary).
Matryoshka HTTP Variant – C2 Communication
One variant of Matryoshka communicates with its command‑and‑control (C2) infrastructure over plain HTTP. It contacts the server at 45.158.196.184:8888, where it performs beaconing to announce its presence, receives commands for execution, exfiltrates collected data, and can download additional tooling or secondary payloads. The HTTP channel allows the attacker to blend with normal web traffic, reducing the likelihood of detection by network‑based IDS/IPS that focus on encrypted or anomalous protocols.
Matryoshka GitHub Variant – Repository‑Based C2
A second variant abandons traditional C2 servers in favor of a private GitHub repository ( adioziaete/memio ). The repository functions as a collection of per‑host “mailboxes”: each compromised endpoint is assigned a unique sub‑directory containing files such as beacon.json (to report status), cmd.json (to receive tasks), result.json (to return outcomes), and optionally an upload/ directory for file transfers. The malware periodically polls the GitHub API for changes in these files, executes any commanded actions, writes back results, and retrieves new payloads from the upload folder. This approach provides the attacker with a versioned, easily updatable C2 infrastructure that leverages GitHub’s reliability and reputation, while also leaving an audit trail of commits unless the repo is purged.
GitHub Repository Details and Actor Attribution Challenges
Investigation of the GitHub account associated with the repository shows it was created on January 6, 2023, and its profile information was last updated on June 7, 2026. Despite these timestamps, the true identity behind the account remains unknown, as no personally identifiable information was linked to the profile. The use of a reputable platform like GitHub further complicates attribution, because defensive tools often whitelist traffic to github.com, and the repository’s activity can mimic legitimate developer workflows.
Strategic Implications – Modularity and Detection Evasion
The overall operation exemplifies a deliberately modular attack chain: each stage (LNK → PowerShell → HollowFrame → side‑loaded container → Matryoshka) carries out a limited, well‑defined function, and no single component contains the full infection logic or complete C2 picture. This compartmentalization hinders signature‑based detection, as antivirus or EDR solutions may only flag isolated behaviors (e.g., a scheduled task or a DLL side‑load) that appear benign in isolation. Moreover, the separation of duties allows the threat actor to swap out or update individual modules without redesigning the entire payload, enhancing the operation’s longevity and adaptability for follow‑on activities such as credential harvesting, lateral movement, and domain‑wide compromise.
Conclusion and Recommendations
The HollowFrame/Matryoshka campaign demonstrates how attackers combine legitimate‑looking file types, living‑off‑the‑land binaries, and reputable third‑party services to achieve stealthy persistence and flexible C2. Defenders should:
- Monitor for abnormal LNK execution followed by PowerShell invocations to external IPs.
- Detect DLL side‑loading anomalies, especially when legitimate executables (python.exe, etc.) load unexpectedly named DLLs.
- Track creation or modification of scheduled tasks that point to non‑standard binaries or scripts.
- Inspect outbound HTTP connections to uncommon ports or IPs (e.g., 45.158.196.184:8888) and correlate with beaconing patterns.
- Audit GitHub API traffic from internal hosts; repeated polling of specific repositories for JSON‑based command/files should raise alerts.
- Employ behavior‑based analytics that look for the combination of persistence mechanisms, anti‑analysis checks, and staged payload delivery rather than relying on any single indicator.
By focusing on the interconnected behaviors that define this multi‑stage threat, organizations can improve their chances of detecting and neutralizing similar intrusion attempts before they mature into full‑scale data theft or network compromise.