Lumma Stealer Malware Detection Guide
Behavioral Indicators
Lumma Stealer exhibits several distinct runtime behaviors that can be detected through process monitoring and endpoint telemetry. The malware typically executes via a loader or dropper that unpacks the main stealer module in memory. A common execution chain involves a parent process (often a legitimate application like a browser or document reader) spawning a suspicious child process, such as cmd.exe or powershell.exe, which then downloads or executes the payload. The stealer itself creates multiple threads to parallelize data theft.
Key API calls to monitor include those related to credential access and data collection. Look for processes making repeated calls to CredEnumerateW and CredReadW to harvest Windows Credential Manager entries. The malware also uses CryptUnprotectData to decrypt browser-stored passwords and cookies from profiles of Chrome, Edge, Firefox, and other Chromium-based browsers. It enumerates files and directories using FindFirstFileW and FindNextFileW, targeting directories like Downloads, Desktop, and cryptocurrency wallet paths (e.g., %AppData%\AtomicWallet, %AppData%\Exodus). To capture clipboard data, it uses GetClipboardData and OpenClipboard in a loop.
Lumma will also attempt to disable security software by querying and terminating processes related to antivirus and EDR solutions using Process32FirstW, Process32NextW, and TerminateProcess. It may inject code into trusted processes like explorer.exe using CreateRemoteThread and WriteProcessMemory to evade detection. A high volume of file reads from browser data directories followed by network connections is a strong behavioral indicator.
Network Indicators
Lumma Stealer communicates with its command-and-control (C2) server using HTTP/HTTPS protocols, often with TLS encryption to obscure traffic. The malware beacons to the C2 at regular intervals, typically between 5 to 15 minutes, but this can vary based on configuration. Beaconing requests often use POST methods with encoded or encrypted payloads containing system information (hostname, username, OS version) as an initial handshake.
DNS queries often precede C2 communication. Look for queries to recently registered domains or domains with algorithmically generated names (e.g., string of random characters). The domains may use Dynamic DNS providers. The malware frequently uses hard-coded IP addresses as fallback C2 servers.
Data exfiltration occurs after the initial beacon. The malware compresses and encrypts stolen data (credentials, cookies, files) before transmitting it via HTTP POST requests to specific URIs. Common URI patterns include paths like /gate.php, /api/collect, or /submit. The User-Agent string in requests may be generic (e.g., Mozilla/5.0) or spoofed to mimic legitimate browser traffic. However, inconsistencies in header order or missing typical browser headers can be detection points.
Monitor for connections to known bad IPs and domains associated with Lumma C2 infrastructure. Outbound connections on ports 443 or 8080 to unfamiliar external IPs, especially following mass file reads from sensitive directories, are suspicious. Use a SIEM platform to correlate internal credential access events with outbound data transfers to external IPs.
File System Artifacts
Lumma Stealer drops several files on the infected system. The initial dropper is often a standalone executable with a generic name like setup.exe, update.exe, or a name masquerading as a document (e.g., invoice.pdf.exe). It may be delivered via phishing attachments or bundled with pirated software.
After execution, Lumma typically creates a working directory in %AppData%, %LocalAppData%, or %Temp%. Common paths include:
%AppData%\Microsoft\Windows\%LocalAppData%\Temp\low\<random_folder>\%Temp%\with a randomly named folder (e.g.,sfx32A1\)
Within these directories, look for the main payload file, often named chrome.exe, security.exe, or a random alphanumeric string with a .exe or .dll extension. The file size of Lumma samples varies but commonly ranges from 200 KB to 500 KB. The malware may also drop a configuration file (e.g., config.bin, settings.dat) containing C2 details and theft parameters.
Lumma creates a log file to record stolen data before exfiltration. This file is usually named logs.txt, data.txt, or output.dat and placed in the same working directory. It is often deleted after successful exfiltration, but remnants may be recoverable. Additionally, the stealer may create a temporary file in %Temp% to store decrypted browser data, with a name like tmp_cookies.txt or passwords.tmp.
Timestamps can be anomalous; the creation time of dropped files may closely match the execution time of the initial dropper (within seconds). Use file integrity monitoring to detect new executables in AppData or Temp directories.
Registry and Persistence Mechanisms
Lumma Stealer employs various methods to maintain persistence on infected systems. A common technique is creating a Run registry key to execute the payload at user logon. Check the following locations:
HKCU\Software\Microsoft\Windows\CurrentVersion\RunHKLM\Software\Microsoft\Windows\CurrentVersion\Run
The registry value name may mimic legitimate software, such as ChromeUpdate or WindowsSecurity, pointing to the path of the dropped executable (e.g., %AppData%\Microsoft\Windows\chrome.exe).
The malware may also use scheduled tasks for persistence. Look for tasks created with names like GoogleUpdateTaskMachine or OneDriveStandaloneUpdate that execute the malicious file. Tasks can be configured to run at logon or at frequent intervals (e.g., every hour). Use command-line auditing to review task actions; suspicious tasks often run from user writable locations like AppData.
Some Lumma variants create Windows service for persistence, particularly on systems with administrative privileges. Service names may be generic, like System32Service or NetworkHelper, with the binary path pointing to the dropped executable. Check service registry paths:
HKLM\System\CurrentControlSet\Services\<service_name>
Additionally, Lumma may abuse file association hijacking, modifying registry keys like HKCU\Software\Classes\txtfile\shell\open\command to execute its payload when a specific file type is opened. It might also use COM object hijacking via registry keys under HKCU\Software\Classes\CLSID\.
For stealth, the malware sometimes uses registry runonce keys, which delete the entry after execution, making detection harder. Monitor for temporary run keys like HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce.
YARA Rule Guidance
When developing YARA rules for Lumma Stealer, focus on unique strings and byte patterns found in unpacked samples. The malware often contains hard-coded strings related to its functionality. Target strings associated with data theft, such as paths for browser data: \\Google\\Chrome\\User Data\\Default\\Login Data, \\Mozilla\\Firefox\\Profiles\\, and \\Opera Software\\Opera Stable\\. Also look for strings related to cryptocurrency wallets like Atomic, Exodus, Electrum, and Coinbase.
Lumma samples frequently include strings for C2 communication, such as POST, /gate.php, User-Agent:, and Content-Type: application/x-www-form-urlencoded. There may also be error or status strings like [+] Stealer started, [*] Sending data..., or [ERROR] Connection failed.
The malware often uses specific API function names in plaintext, such as CryptUnprotectData, CredEnumerateW, and GetClipboardData. These can be useful as detection strings. Additionally, look for configuration strings like config, server, delay, and antivirus that may appear in the binary.
For byte patterns, examine the PE structure. Lumma payloads are typically compiled with certain compilers (like GCC or MinGW) and may have consistent section names (e.g., .text, .data) and entry point characteristics. Some variants use simple XOR encryption for strings; consider including decryption loops or XOR constants in your rule logic.
Avoid targeting overly generic strings. Combine multiple strings with conditions on file size and section counts to reduce false positives. Focus on the unique combination of credential theft, browser targeting, and C2 communication patterns specific to Lumma.
For the latest samples, IOCs, and a comprehensive overview, refer to the Lumma Stealer resources: Current Samples, Current IOCs, and Lumma Stealer Overview.