Felipe Duarte: Raspberry Robin: Evolution of an advanced malware downloading framework | CONFidence

### Overview In this presentation, Felipe Duarte, Threat Research Lead at Security Joes, examines the architecture and evasion techniques of the Raspberry Robin worm. Raspberry Robin functions primarily as an advanced malware loader and distribution botnet designed to establish stealthy persistence, filter target environments, and deliver high-impact second-stage payloads such as IcedID, TrueBot, or Clop ransomware. Duarte focuses on how the threat actors behind Raspberry Robin actively study analysts and implement deception mechanisms to mislead defenders and automated sandboxes.

### Key Topics - **Infection and Distribution Vectors:** Duarte details two primary distribution methods. The first relies on infected USB drives using `.lnk` shortcut files that launch command lines directing `msiexec.exe` to download malicious MSI packages from compromised QNAP NAS devices. The second vector utilizes malvertising campaigns delivering ZIP archives that contain encrypted Microsoft JScript (`.jse`) files, which ultimately drop DLLs invoked via `regsvr32.exe`. - **Abuse of Legitimate Infrastructure:** The operators leverage trusted cloud and web services—including GitHub, Microsoft Azure, and Discord—to stage payloads and collect campaign telemetry, tracking the efficacy of their malvertising operations. - **Sophisticated Obfuscation:** The loader incorporates extensive anti-analysis barriers, including at least eight distinct layers of shellcode and packers, junk instructions, indirect execution calls via the stack, and a finite state machine (FSM) to obfuscate control flow. - **Analyst Deception via Fake Payloads:** Rather than merely terminating when sandboxes or debugging environments are detected, Raspberry Robin triggers a decoy downloader payload. This fake payload collects analyst environment data, transmits it to a QNAP C2 server via RC4 encryption, and executes benign or fake files to mislead triage processes.

### Technical Details - **Execution and Memory Clean-up:** Duarte illustrates an indirect call pattern using the stack: the malware pushes the shellcode address (in `ECX`), pushes the main DLL address (in `EAX`), and executes a `jmp` to the Windows API `VirtualFree`. This alters the return address to transfer execution directly into the shellcode while simultaneously freeing and unmapping the initial DLL from memory. - **Environment Fingerprinting:** The malware examines the Process Environment Block (PEB) for debugging flags, inspects process paths and file names for analysis strings (e.g., 'sample'), queries CPU details, and checks physical disk product IDs. It also cross-checks current usernames and computer names against a hardcoded blocklist embedded within the binary. - **Decoy Pipeline vs. Real Payload:** When an analysis environment or sandbox (such as Joe Sandbox) is identified, the malware runs a fake payload that queries display devices via `EnumDisplayDevices`, profiles the host, communicates with a QNAP C2 server over RC4, and downloads a decoy file. This deception trick feeding fake telemetry back to the attackers allows them to profile sandboxes and harvest analyst metadata. Conversely, on a clean, valid target, the real loader communicates exclusively over the Tor network to download shellcode or secondary payloads like IcedID, TrueBot, or Clop ransomware.

### Takeaways Defenders should maintain targeted threat hunting rules, such as flagging `msiexec.exe` fetching remote files from external URLs, and monitoring `regsvr32.exe` invoking extensionless files out of temporary directories (`\Temp`). Organizations must also closely monitor suspicious outbound Tor connections. Finally, Duarte emphasizes that malware triage must not rely solely on automated sandbox success reports: observed C2 traffic and simple downloader activity may be intentionally staged decoys engineered to deceive analysts and gather intelligence on defensive environments.