A new malware loader that researchers are calling Sauron Loader has been spotted in attacks against organizations in Germany, using a layered evasion technique built around DLL side-loading and code that only ever exists, in decrypted form, inside a computer's memory.
What happened
The loader is reportedly being sold on Russian-speaking cybercrime forums, with the seller said to impose some restrictions on who can buy it and which targets are off-limits — though the identity of the operators behind the German intrusions has not been confirmed. Once it gains a foothold on a machine, Sauron Loader can pull down and run additional programs, gather information about the infected system and its user, and relay that data back to its controllers. Investigators have not yet determined how many systems have been affected, or what final-stage malware, if any, was delivered in the incidents reviewed so far.
How it evades detection
The infection chain starts with a Windows installer that drops a genuine, trusted executable alongside two malicious support libraries. When the trusted program runs, it loads one of those libraries instead of its real dependency — a classic DLL side-loading trick that lets malicious code start under the cover of a legitimate process.
The first library doesn't contain readable malicious code at all: its payload is encrypted. It hands off to a second library, which decrypts the loader's real logic directly in memory and passes control to it, so nothing incriminating ever touches disk in a form a file scanner could flag. The malware also builds in a deliberate delay before continuing execution — a stalling tactic aimed at automated sandboxes that only watch a sample for a short window.
For persistence, the second library creates a scheduled task with an innocuous name that restarts the loader at intervals, keeping access alive without running as an obvious standalone malicious process. Researchers note the installer they examined is only one distribution path — related samples share the same core mechanics but connect to different command-and-control infrastructure, meaning defenders can't assume blocking one variant covers the whole family.
What the loader does once active
After establishing itself, Sauron Loader reads a hidden configuration block that tells it where to connect and how to behave. It registers details about the infected machine, including computer name and Windows version, then checks in for instructions over encrypted HTTPS traffic that rotates its request paths to blend in with normal web activity. From there, operators can instruct it to download and run additional executables, libraries, installers, or scripts, and the loader can also capture and exfiltrate screenshots in smaller chunks — behavior consistent with a delivery platform for whatever later-stage malware an operator chooses to push, rather than a single fixed payload.
Some infections reportedly began with social engineering rather than a drive-by install: in at least one case, a caller convinced a target to start a remote-assistance session, echoing tactics seen in unrelated fake-support and "email bombing" campaigns used to gain remote access.
Why it matters
DLL side-loading and in-memory decryption are both designed to defeat exactly the controls most organizations rely on — signature-based antivirus and static file scanning. A loader that can silently stage further payloads on demand is a foothold that can turn into anything from ransomware to data theft, depending on what the operator decides to push next.
What to do
- Monitor for unexpected DLLs loading alongside otherwise legitimate, signed executables, particularly from installer directories such as
C:\ProgramData. - Alert on newly created scheduled tasks with generic or misleading names that relaunch a process at regular intervals.
- Inspect outbound HTTPS connections for unusual request-path patterns rather than relying solely on domain reputation, since command-and-control infrastructure rotates.
- Treat unsolicited helpdesk or IT-support contact — especially following a sudden flood of inbox notifications — as a red flag, and never run remote-assistance commands presented as a "quick fix" without independently verifying the request through a known internal channel.
- Share indicators of compromise with your SOC or MSSP so installer hashes, side-loaded library names, and known command-and-control domains can be blocked at the perimeter.