Detecting Lumma Stealer
Ontinue’s Threat Detection team recently received an unusual detection request. Our SOC previously had observed a sharp increase of information stealer attacks across our customer base and a number of our customers had been compromised by the Lumma Stealer malware. (We recently reported on the rise of information stealers in our 2H 2024 Threat Intelligence Report, more on that here.) But this request was not about detecting the Lumma Stealer, as our EDR, Microsoft Defender for Endpoint (MDE) was already detecting and alerting on different behaviors of the malware. The problem was that the alerts generated by MDE still required manual triaging by our Cyber Defenders to attribute them to the Lumma Stealer malware and initiate appropriate response steps. What was needed was a faster, more accurate detection for Lumma and other information stealers, allowing the ION MXDR platform to respond quickly to this type of threat, ideally in an automated fashion without human intervention.
What is Lumma?
Lumma is an information-stealing malware written in C that is designed to steal sensitive information. The malware has been observed being used as Malware-as-a-Service (MaaS), which was seen on Russian-speaking forums starting around 2022. Once the malware infects the target host, it attempts to steal information from the endpoint and then exfiltrate it to the command and control server. For a full analysis of the malware including insights into the tactics, techniques, and procedures (TTPs), read our previous blog post.
In the first quarter of 2025 alone, the Ontinue SOC observed approximately twice the number of Lumma-related incidents reported in the entire year of 2024. A trend that will likely continue throughout the year.
When it comes to information stealers such as Lumma time-to-contain (MTTC) is key. Initial Access Brokers (IAB) use information stealers to collect and exfiltrate sensitive information which they then sell to other threat actors to weaponize for follow-up attacks. Therefore, the sooner the flow of information is stopped, the less likely it is that the exfiltrated data puts the organization at risk.
Automated containment
The ION MXDR platform offers a comprehensive library of over 80 automation skills that support our Cyber Defenders in the triaging process. This library includes incident enrichment and information gathering skills, as well as workflows for automated incident response. One such workflow involves isolating compromised hosts, which was deemed an appropriate response to information stealer malware as it immediately halts the flow of information. However, since executing this skill would isolate a device from the network, potentially impacting customer operations, it required a highly reliable and precise trigger to avoid benign positives or false positives.
Detecting Lumma
The threat detection team explored multiple options for detecting Lumma. While MDE reliably detects various aspects of Lumma Stealer, none of the alerts could be specifically attributed to that malware, making them insufficient as triggers for automated response actions. Therefore, the first option was to develop a correlation use case based on multiple MDE signatures related to Lumma.
Detecting Lumma through correlation of MDE alerts
Attacks involving the Lumma malware typically begin with social engineering or malvertising campaigns that trick victims into executing malicious commands using fake CAPTCHAs in the Windows Run dialog box. This activity was observed triggering the following MDE alerts:
- Suspicious command in RunMRU registry
- An active ‘ClickFix’ malware in a command line was prevented from executing
If the victim falls for the lure and follows the instructions, a malicious command is executed by leveraging a benign executable already present on the victim’s device, in many cases powershell.exe or mshta.exe. This typically triggers the following MDE alerts:
- Suspicious PowerShell command line
- Suspicious mshta process launched
- Possible initial access from an emerging threat
Examples of LOLBins being executed to download malicious commands
The logic for detecting Lumma based on MDE alerts was straightforward: correlate alerts related to suspicious activity in the Windows Run dialog box, followed by alerts related to suspicious PowerShell or mshta processes, all within a 10-minute window.
Although the detection logic proved accurate for identifying Lumma, a significant flaw soon became apparent. While MDE accurately detects malicious activities, we observed a delay of 5-7 minutes between the occurrence of malicious activity, as seen in MDE’s telemetry, and the generation of the alert within the Defender XDR portal. Additionally, there was an extra 1-2 minute delay for alert synchronization between Defender XDR and Sentinel, where our query was executed. Although the alert correlation was accurate, it did not meet our requirement for a timely trigger for our automated response workflow. Therefore, we had to explore alternative options.
Detecting Lumma with Defender telemetry
One of our skilled Cyber Defenders provided the building blocks of this detection, which he came up with during a customer engagement. The query only required minor adjustments to make the detection more resilient to changing TTPs.
The observed attack patterns consistently involved the victim executing a malicious command in the Windows Run dialog box. All commands which are executed in this manner are stored in the Windows registry at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. The suspicious command lines observed in Lumma and other information stealers usually involve a URL passed to either powershell or mshta. Therefore, the first part of our detection monitored registry key changes reported by MDE in the DeviceRegistryEvents table, focusing on instances where the RunMRU registry key contained indicators of a URL being passed.
DeviceRegistryEvents
| where ActionType == "RegistryValueSet"
| where RegistryKey endswith @"\CurrentVersion\Explorer\RunMRU"
| where RegistryValueData has_any ("http","https")
| extend URL = tolower(extract(@"http[s]?://[^\s'""\)\>,]+", 0, RegistryValueData))
| where isnotempty(URL)
The RunMRU registry key stores all commands executed in the Windows Run dialog box.
The second part of the detection logic focused on the malicious commands being executed. The first version of the query monitored powershell.exe and mshta.exe since those binaries where observed being abused in the field. However, it is likely that threat actors will pivot away to other living-off-the-land binaries. Therefore, the query was extended to observe additional binaries. The LOLBAS project (https://lolbas-project.github.io/# ) curates a list of binaries which are benign themselves but can be abused for malicious purposes.
We utilized KQL’s externaldata operator (https://learn.microsoft.com/en-us/kusto/query/externaldata-operator) to download the CSV file curated by the LOLBAS project and match it against process creation events reported by MDE in the DeviceProcessEvents table. Naturally, the list included many binaries from web browsers, which added significant noise. However, as threat actors had not been observed leveraging browsers for their malicious downloads, those binaries could be excluded from the detection logic, provided they where in their expected locations within the users profile folder or installed in either of the Program Files folders. The resulting detection logic included only process creation events where one of the LOLBins was passed a URL.
DeviceProcessEvents
| where FileName in~ (externaldata(FileName:string) [@"https://lolbas-project.github.io/api/lolbas.csv"]) or FileName in~ ('powershell.exe')
| where not ( FileName in~ ('msedge.exe','msedge_proxy.exe','chrome.exe','firefox.exe','brave.exe','opera.exe','vivaldi.exe') and // Exclude common browser binaries
FolderPath has_any (@'\Program Files\',@'\Program Files (x86)\',@'\AppData\Local\'))
| where ProcessCommandLine has_any ("http","https")
| extend URL = tolower(extract(@"http[s]?://[^\s'""\)\>,]+", 0, ProcessCommandLine))
| where isnotempty(URL) // Ensure only valid URLs are captured
LOLBins are abused to download malicious payloads by passing URLs to them.
To finalize our detection, we correlated the results from the first part of the query, which surfaces suspicious registry activities, with suspicious process creation events based on the URL. The resulting query alerts on LOLBins launched from the Windows Run dialog box and being abused to download web content.
let queryPeriod = 10m;
let RegistryActivity = DeviceRegistryEvents
| where ingestion_time() > ago(queryPeriod)
| where ActionType == "RegistryValueSet"
| where RegistryKey endswith @"\CurrentVersion\Explorer\RunMRU"
| where RegistryValueData has_any ("http","https")
| extend URL = tolower(extract(@"http[s]?://[^\s'""\)\>,]+", 0, RegistryValueData))
| where isnotempty(URL)
| summarize RegistryActivityTime = min(TimeGenerated) by DeviceName, RegistryKey, RegistryValueData, URL;
let SuspiciousCommandLineActivity = DeviceProcessEvents
| where ingestion_time() > ago(queryPeriod)
| where FileName in~ (externaldata(FileName:string) [@"https://lolbas-project.github.io/api/lolbas.csv"]) or FileName in~ ('powershell.exe')
| where not ( FileName in~ ('msedge.exe','msedge_proxy.exe','chrome.exe','firefox.exe','brave.exe','opera.exe','vivaldi.exe') and // Exclude common browser binaries
FolderPath has_any (@'\Program Files\',@'\Program Files (x86)\',@'\AppData\Local\'))
| where ProcessCommandLine has_any ("http","https")
| extend URL = tolower(extract(@"http[s]?://[^\s'""\)\>,]+", 0, ProcessCommandLine))
| where isnotempty(URL) // Ensure only valid URLs are captured
| summarize SuspiciousCommandLineActivityTime = min(TimeGenerated) by DeviceName, ProcessCommandLine, URL;
SuspiciousCommandLineActivity
| join kind = inner (RegistryActivity) on URL, DeviceName
| extend HostName = tostring(split(DeviceName, '.', 0)[0]), DnsDomain = tostring(strcat_array(array_slice(split(DeviceName, '.'), 1, -1), '.'))
| project RegistryActivityTime, SuspiciousCommandLineActivityTime, DeviceName, HostName, DnsDomain, ProcessCommandLine, RegistryKey, RegistryValueData, URL
Full query to detect Lumma Stealer based on Windows Run dialog box and LOLBIN activity.
This new use case was assigned to the auto-isolation automation skill and has since protected our customers from the Lumma Stealer malware.
Reducing the attack surface further
Ontinue MXDR successfully protects our customers from the impact of information-stealing malware such as Lumma. Customers looking to reduce their attack surface further against this type of attack should consider disabling the Windows Run dialog box for their users. This can be achieved through group policy with the setting: “Remove Run menu from Start Menu“.
For more information on the Lumma C2 Stealer, here are a few blogs you’ll want to read:
Mathias Sigrist
Senior Detection Engineer
Mathias is a Senior Detection Engineer on the Threat Detection team at Ontinue.
