Blog

Erkennung von Lumma-Stealern

Das Bedrohungserkennungsteam von Ontinue erhielt kürzlich eine ungewöhnliche Erkennungsanfrage. Unser SOC-Team hatte zuvor eine starke Zunahme von Informationsdiebstahlsangriffen auf unseren Kundenstamm beobachtet, und eine Reihe unserer Kunden war durch die Lumma-Stealer-Malware gefährdet worden. (Wir haben kürzlich in unserem Threat Intelligence Report 2H 2024 über die Zunahme von Informationsdiebstählen berichtet, mehr dazu hier.) Bei dieser Anfrage ging es jedoch nicht um die Erkennung von Lumma Stealer, da unser EDR, Microsoft Defender for Endpoint (MDE), bereits verschiedene Verhaltensweisen der Malware erkannte und entsprechende Warnungen ausgab. Das Problem war, dass die von MDE generierten Warnungen immer noch manuell von unseren Cyber Defenders bewertet werden mussten, um sie der Lumma Stealer-Malware zuzuordnen und entsprechende Reaktionsschritte einzuleiten. Benötigt wurde eine schnellere und präzisere Erkennung von Lumma und anderen Informationsdieben, damit die ION MXDR-Plattform schnell auf diese Art von Bedrohung reagieren kann, idealerweise automatisch und ohne menschliches Eingreifen.


Was ist Lumma?

Lumma ist eine in C geschriebene Malware, die vertrauliche Informationen stehlen soll. Es wurde beobachtet, dass die Malware als Malware-as-a-Service (MaaS) eingesetzt wird, was in russischsprachigen Foren ab etwa 2022 beobachtet wurde. Sobald die Malware den Zielhost infiziert hat, versucht sie, Informationen vom Endpunkt zu stehlen und sie dann an den Command-and-Control-Server zu übermitteln. Eine vollständige Analyse der Malware mit Einblicken in die Taktiken, Techniken und Verfahren (TTPs), Lesen Sie unseren früheren Blogbeitrag.

Allein im ersten Quartal 2025 wurden im Ontinue SOC etwa doppelt so viele Vorfälle im Zusammenhang mit Lumma gemeldet wie im gesamten Jahr 2024. Ein Trend, der sich wahrscheinlich im Laufe des Jahres fortsetzen wird.

Ein Balkendiagramm, das die Anzahl der Vorfälle im Zusammenhang mit Lumma Stealer zeigt. Die Balken stellen Daten für 2023, 2024 und Q1 2025 dar, mit einem deutlichen Anstieg der Vorfälle im Q1 2025.

Bei Informationsdieben wie Lumma ist die Time-to-Contain (MTTC) entscheidend. Initial Access Brokers (IAB) verwenden Information Stealer, um sensible Informationen zu sammeln und zu exfiltrieren, die sie dann an andere Bedrohungsakteure verkaufen, um sie für Folgeangriffe zu nutzen. Je früher der Informationsfluss gestoppt wird, desto geringer ist die Wahrscheinlichkeit, dass die exfiltrierten Daten ein Risiko für das Unternehmen darstellen.


Automatischer Einschluss

Die ION MXDR-Plattform bietet eine umfassende Bibliothek mit über 80 Automatisierungsfähigkeiten, die unsere Cyber Defenders beim Triaging-Prozess unterstützen. Diese Bibliothek umfasst Skills zur Anreicherung von Vorfällen und zur Informationsbeschaffung sowie Workflows für die automatisierte Reaktion auf Vorfälle. Einer dieser Workflows beinhaltet die Isolierung kompromittierter Hosts, was als angemessene Reaktion auf Informationsdiebstahl-Malware angesehen wurde, da es den Informationsfluss sofort stoppt. Da die Ausführung dieser Fähigkeit jedoch ein Gerät vom Netzwerk isolieren würde, was sich möglicherweise auf den Kundenbetrieb auswirken würde, war ein äußerst zuverlässiger und präziser Auslöser erforderlich, um gutartige oder falsch-positive Ergebnisse zu vermeiden.


Lumma aufspüren

Das Bedrohungserkennungsteam untersuchte mehrere Optionen zur Erkennung von Lumma. Obwohl MDE verschiedene Aspekte von Lumma Stealer zuverlässig erkennt, konnte keine der Warnungen speziell dieser Malware zugeordnet werden, so dass sie als Auslöser für automatische Reaktionsmaßnahmen nicht ausreichten. Daher bestand die erste Option darin, einen Korrelationsanwendungsfall zu entwickeln, der auf mehreren MDE-Signaturen basiert, die sich auf Lumma beziehen.

Erkennung von Lumma durch Korrelation von MDE-Warnungen

Angriffe mit Lumma-Malware beginnen in der Regel mit Social-Engineering- oder Malvertising-Kampagnen, bei denen die Opfer durch gefälschte CAPTCHAs im Windows-Ausführen-Dialogfeld dazu gebracht werden, bösartige Befehle auszuführen. Diese Aktivität wurde beobachtet und löste die folgenden MDE-Warnungen aus:

  • Verdächtiger Befehl in der RunMRU-Registrierung
  • Eine aktive ‘ClickFix’-Malware in einer Befehlszeile wurde an der Ausführung gehindert
Eine Grafik mit den Überprüfungsschritten auf weißem Hintergrund. Die Textanweisungen umfassen: 1. Drücken Sie die Windows-Taste + R, 2. drücken Sie CTRL + V, 3. drücken Sie die Eingabetaste. Der Titel lautet 'Überprüfungsschritte' in blauer Schrift.

Wenn das Opfer auf die Verlockung hereinfällt und den Anweisungen folgt, wird ein bösartiger Befehl ausgeführt, indem eine harmlose ausführbare Datei genutzt wird, die bereits auf dem Gerät des Opfers vorhanden ist, in vielen Fällen powershell.exe oder mshta.exe. Dies löst in der Regel die folgenden MDE-Warnungen aus:

  • Verdächtige PowerShell-Befehlszeile
  • Verdächtiger mshta-Prozess gestartet
  • Möglicher Erstzugang durch eine neue Bedrohung

Beispiele für LOLBins, die zum Herunterladen bösartiger Befehle ausgeführt werden

Die Logik für die Erkennung von Lumma auf der Grundlage von MDE-Warnungen war einfach: Korrelation von Warnmeldungen im Zusammenhang mit verdächtigen Aktivitäten im Windows-Dialogfeld "Ausführen", gefolgt von Warnmeldungen im Zusammenhang mit verdächtigen PowerShell- oder mshta-Prozessen, alle innerhalb eines 10-Minuten-Fensters.

Ein digitales Protokoll mit Sicherheitswarnungen in Bezug auf verdächtige Aktivitäten, einschließlich PowerShell-Befehle und mshta-Prozesse, die von Microsoft Defender for Endpoint erkannt wurden. Die Warnungen zeigen unterschiedliche Schweregrade an.

Obwohl sich die Erkennungslogik bei der Identifizierung von Lumma als akkurat erwies, wurde bald ein erheblicher Fehler deutlich. Während MDE bösartige Aktivitäten genau erkennt, beobachteten wir eine Verzögerung von 5-7 Minuten zwischen dem Auftreten bösartiger Aktivitäten, wie sie in der Telemetrie von MDE zu sehen sind, und der Generierung der Warnung im Defender XDR-Portal. Außerdem gab es eine zusätzliche Verzögerung von 1 bis 2 Minuten für die Synchronisierung der Warnmeldungen zwischen Defender XDR und Sentinel, wo unsere Abfrage ausgeführt wurde. Obwohl die Korrelation der Warnmeldungen korrekt war, erfüllte sie nicht unsere Anforderungen an einen zeitnahen Auslöser für unseren automatischen Reaktionsworkflow. Daher mussten wir nach alternativen Möglichkeiten suchen.

Eine Tabelle, in der die Zeitleisten bösartiger Aktivitäten von zwei Geräten verglichen werden, mit Zeitstempeln, Aktivitäten von Registrierungsschlüsseln und Warnungen in Bezug auf potenzielle Bedrohungen, mit Schwerpunkt auf der Erkennung von Lumma Infostealer.

Erkennung von Lumma mit Defender-Telemetrie

Einer unserer erfahrenen Cyber Defenders lieferte die Bausteine für diese Erkennung, die er während eines Kundeneinsatzes entwickelt hatte. Die Abfrage musste nur geringfügig angepasst werden, um die Erkennung widerstandsfähiger gegenüber sich ändernden TTPs zu machen.

Bei den beobachteten Angriffsmustern führte das Opfer stets einen bösartigen Befehl im Dialogfeld "Ausführen" von Windows aus. Alle Befehle, die auf diese Weise ausgeführt werden, werden in der Windows-Registrierung unter HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU. Die verdächtigen Befehlszeilen, die bei Lumma und anderen Datendieben beobachtet werden, enthalten in der Regel eine URL, die entweder an powershell oder mshta übergeben wird. Daher überwachte der erste Teil unserer Erkennung die von MDE gemeldeten Änderungen der Registrierungsschlüssel in der DeviceRegistryEvents Tabelle, wobei der Schwerpunkt auf Fällen liegt, in denen die RunMRU Registrierungsschlüssel enthielt Indikatoren für die Übermittlung einer URL.

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)

Die RunMRU Der Registrierungsschlüssel speichert alle Befehle, die im Dialogfeld Ausführen von Windows ausgeführt werden.

Der zweite Teil der Erkennungslogik konzentrierte sich auf die bösartigen Befehle, die ausgeführt wurden. Die erste Version der Abfrage überwachte powershell.exe und mshta.exe da beobachtet wurde, dass diese Binärsysteme in der Praxis missbraucht wurden. Es ist jedoch wahrscheinlich, dass die Bedrohungsakteure auf andere Binärdateien ausweichen, die nicht an Land leben. Daher wurde die Abfrage erweitert, um weitere Binärsysteme zu beobachten. Das LOLBAS-Projekt (LOLBAS-Projekt ) kuratiert eine Liste von Binärdateien, die an sich gutartig sind, aber für bösartige Zwecke missbraucht werden können.

Wir nutzten KQL's externe Daten Betreiber (Microsoft Kusto Abfragesprache (KQL)), um die vom LOLBAS-Projekt kuratierte CSV-Datei herunterzuladen und sie mit den von MDE gemeldeten Ereignissen zur Prozesserstellung in der DeviceProcessEvents Tabelle. Natürlich enthielt die Liste viele Binärdateien aus Webbrowsern, die ein erhebliches Rauschen verursachten. Da jedoch nicht beobachtet wurde, dass Bedrohungsakteure Browser für ihre bösartigen Downloads nutzen, konnten diese Binärdateien von der Erkennungslogik ausgeschlossen werden, vorausgesetzt, sie befanden sich an ihrem erwarteten Speicherort im Profilordner des Benutzers oder waren in einem der folgenden Ordner installiert Programm-Dateien Ordnern. Die sich daraus ergebende Erkennungslogik umfasste nur Prozess-Erstellungsereignisse, bei denen einer der LOLBins eine URL übergeben wurde.

DeviceProcessEvents
| where FileName in~ (externaldata(FileName:string) [@"https://lolbas-project.github.io/api/lolbas.csv"]) oder FileName in~ ('powershell.exe')
| where not ( FileName in~ ('msedge.exe','msedge_proxy.exe','chrome.exe','firefox.exe','brave.exe','opera.exe','vivaldi.exe') and // Gemeinsame Browser-Binaries ausschließen
  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) // Sicherstellen, dass nur gültige URLs erfasst werden

LOLBins werden missbraucht, um bösartige Nutzdaten herunterzuladen, indem URLs an sie übergeben werden.

Um unsere Erkennung abzuschließen, haben wir die Ergebnisse aus dem ersten Teil der Abfrage, der verdächtige Registrierungsaktivitäten aufzeigt, mit verdächtigen Prozesserstellungsereignissen auf der Grundlage der URL korreliert. Die daraus resultierende Abfrage warnt vor LOLBins, die über das Dialogfeld "Ausführen" von Windows gestartet und zum Herunterladen von Webinhalten missbraucht werden.

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"]) oder FileName in~ ('powershell.exe')
| where not ( FileName in~ ('msedge.exe','msedge_proxy.exe','chrome.exe','firefox.exe','brave.exe','opera.exe','vivaldi.exe') and // Gemeinsame Browser-Binaries ausschließen
  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) // Sicherstellen, dass nur gültige URLs erfasst werden
| SuspiciousCommandLineActivityTime = min(TimeGenerated) by DeviceName, ProcessCommandLine, URL zusammenfassen;
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), '.'))
| Projekt RegistryActivityTime, SuspiciousCommandLineActivityTime, DeviceName, HostName, DnsDomain, ProcessCommandLine, RegistryKey, RegistryValueData, URL

Vollständige Abfrage zur Erkennung von Lumma Stealer auf der Grundlage des Windows-Dialogfelds Ausführen und der LOLBIN-Aktivität.

Dieser neue Anwendungsfall wurde der Fähigkeit zur automatischen Isolierung zugewiesen und hat unsere Kunden seitdem vor der Lumma-Stealer-Malware geschützt.


Weitere Verringerung der Angriffsfläche

Ontinue MXDR schützt unsere Kunden erfolgreich vor den Auswirkungen von Malware, die Informationen stiehlt, wie z. B. Lumma. Kunden, die ihre Angriffsfläche gegen diese Art von Angriffen weiter reduzieren möchten, sollten in Erwägung ziehen, das Windows-Dialogfeld “Ausführen“ für ihre Benutzer zu deaktivieren. Dies kann über die Gruppenrichtlinie mit der Einstellung erreicht werden: "Ausführen-Menü aus Startmenü entfernen".

Ein Computerbildschirm, der die Oberfläche des Editors für lokale Gruppenrichtlinien anzeigt und die Einstellung 'Menü Ausführen aus dem Startmenü entfernen' unter der Kategorie 'Startmenü und Taskleiste' hervorhebt.

Weitere Informationen über den Lumma C2 Stealer finden Sie in einigen Blogs, die Sie lesen sollten:

Teilen

Artikel von

Mathias Sigrist

Leitender Ingenieur für Detektion

Mathias ist Senior Detection Engineer im Threat Detection Team bei Ontinue.