ACR Stealer: zwei Lieferketten, ein Datendiebstahlziel

Prüfauftrag, Stand und Beleggrenze

Zwei von Microsoft Defender Experts zwischen Ende April und Mitte Juni 2026 beobachtete ACR-Stealer-Kampagnen. Die Leitfrage lautet: Welche Architektur- und Verhaltensaussagen trägt dieser konkrete Prüfstand, und welche bleiben ausschließlich der Quelle zugeschrieben?

Was belegt ist — und was fehlt

Primärquellen, statisch prüfbarer Code und Laufzeitbeobachtungen haben unterschiedliche Aussagekraft. Die Karte hält diese Ebenen auseinander; fehlende Eigenbeobachtung wird nicht durch Plausibilität ersetzt.

Eintritt und Lieferkette

Beide beobachteten Ketten beginnen mit ClickFix: Das Opfer führt einen vorgegebenen Befehl aus. Kette A lädt per rundll32 eine DLL von einer HTTPS-WebDAV-Freigabe, nutzt verschleiertes PowerShell und startet einen gebündelten Python-Interpreter. Kette B wechselt über PowerShell zu MSHTA, einer entfernten HTA und speicherbasierter Ausführung.

Architektur und Datenfluss

Kette A installiert ein ZIP-Paket unter einem täuschend benannten LocalAppData-Pfad, startet pythonw ohne Konsole und kann C2-Ziele über eine Blockchain-Dead-Drop-Referenz auflösen. Kette B transportiert ein verschlüsseltes Payload in JPEG-Daten und lädt es reflektiv. Gemeinsam ist erst das Stealer-Ziel, nicht der Loaderbau.

Analyseabwehr und Persistenz

Arithmetische No-ops, tote Schleifen, zufällige Variablennamen, Headless-Conhost, Zeitstempeländerung und gelöschte Kommandohistorie erschweren Einzelartefakt-Erkennung. Diese Techniken sind nicht exklusiv für ACR; aussagekräftig wird ihre zeitliche Verbindung mit WebDAV, MSHTA oder Browserzugriff.

Fähigkeiten, Ziel und Wirkung

Das dokumentierte Ziel sind Browserpasswörter, Sitzungstoken, Authentifizierungsartefakte und sensible Dokumente. Ein Stealer-Fund belegt damit ein Risiko für nachgelagerte Konto- und Cloudzugriffe, aber nicht automatisch deren tatsächliche Nutzung.

Telemetrieplan und Beweiskette

Detektion sollte den gemeinsamen menschlichen Einstieg und beide technischen Abzweige modellieren: Explorer oder Run-Dialog zu cmd/PowerShell, rundll32 mit WebDAV, pythonw aus benutzerbeschreibbaren Pfaden, MSHTA mit Remote-URL und anschließender Zugriff auf Browserdaten. Einzelne LOLBins bleiben zu breit. Für eine belastbare Untersuchung werden Prozess-GUID und vollständige Elternkette, Nutzer und Sitzung, Befehlszeile, Signatur- und Hashstatus, Datei- und Registryänderungen, DNS-/Verbindungsziele sowie nachgelagerte Zugriffe auf sensible Daten in einer gemeinsamen Zeitleiste erhalten. Zeitnähe ist dabei ein Belegparameter, keine bloße Visualisierung. Fehlende Sensorabdeckung wird pro Stufe markiert, damit ein nicht sichtbares Ereignis nicht fälschlich als nicht erfolgt gilt.

Detection Engineering und Gegenprüfung

Detektion sollte den gemeinsamen menschlichen Einstieg und beide technischen Abzweige modellieren: Explorer oder Run-Dialog zu cmd/PowerShell, rundll32 mit WebDAV, pythonw aus benutzerbeschreibbaren Pfaden, MSHTA mit Remote-URL und anschließender Zugriff auf Browserdaten. Einzelne LOLBins bleiben zu breit. Das folgende Modell ist bewusst eng, nicht engine-validiert und muss gegen legitime Administrations- und Softwarepfade getestet werden.

1title: ACR chain-B MSHTA handoff candidate
2status: experimental
3logsource:
4  product: windows
5  category: process_creation
6detection:
7  selection:
8    Image|endswith: '\\mshta.exe'
9    CommandLine|contains: 'http'
10    ParentImage|endswith: '\\powershell.exe'
11  condition: selection
12falsepositives:
13  - Legitimate administrative or software activity with the same isolated pattern
14level: medium

Alternativhypothesen und Negativtests

Vor einer Familienzuordnung werden die im Modell verwendeten Einzelmerkmale getrennt gegen Softwareverteilung, Administratorwerkzeuge, Installer, Browser- oder Backupsoftware und bekannte interne Skripte geprüft. Mindestens ein struktureller Anker und eine zeitlich passende Verhaltenskette müssen zusammenpassen. Microsoft bezeichnet die zwei Ketten ausdrücklich als repräsentativ, nicht vollständig. Die Zuordnung stützt sich auf Verhalten und OSINT-Korroboration; WebDAV-, Blockchain- oder MSHTA-Nutzung allein ist kein Familienbeweis. Ein negativer Gegencheck verwirft nur die geprüfte Hypothese; er ist keine allgemeine Entwarnung.

Attribution und Variantenrisiko

Microsoft bezeichnet die zwei Ketten ausdrücklich als repräsentativ, nicht vollständig. Die Zuordnung stützt sich auf Verhalten und OSINT-Korroboration; WebDAV-, Blockchain- oder MSHTA-Nutzung allein ist kein Familienbeweis.

Abschließende Bewertung

Die Analyse liefert eine belastbare Architektur- und Detektionsgrundlage für den benannten Stand. Sie ist kein Beweis für aktuelle Aktivität, vollständige Variantenabdeckung oder einen bestimmten Betreiber.

Grenzen der Prüfung

• Keine unabhängige Sample-, Laufzeit-, C2- oder Kampagnenverifikation.
• Microsoft bezeichnet die zwei Ketten ausdrücklich als repräsentativ, nicht vollständig. Die Zuordnung stützt sich auf Verhalten und OSINT-Korroboration; WebDAV-, Blockchain- oder MSHTA-Nutzung allein ist kein Familienbeweis.
• Defensive Modelle sind nicht mit einer Zielengine validiert.