UNC7017 zielt auf AOMEI Technology in Angriff auf Lieferkette von Software
Detection stack
- AIDR
- Alert
- ETL
- Query
Zusammenfassung
UNC7017 führte eine ausgeklügelte Software-Lieferkettenkampagne durch, die auf die Aktualisierungsinfrastruktur von AOMEI Technology abzielte. Die Bedrohungsakteure nutzten kurze Konfigurationsänderungsfenster, um Aktualisierungsanfragen zu bösartigen Servern umzuleiten und so traditionelle zeitpunktbezogene Prüfungen zu umgehen. Die Kampagne lieferte eine mehrstufige Payload-Kette, die den CROSSROAD-Downloader und die SHINYROAD-Backdoor einschloss.
Untersuchung
Die Untersuchung wurde gemeinsam von der Mandiant Google Threat Intelligence Group (GTIG) und dem ManageEngine Threat Analysis Lab (METAL) durchgeführt. Forscher entdeckten die Kampagne durch EDR-Telemetrie und bestätigten, dass die Gegner auf flüchtige Manipulationsfenster angewiesen waren, die nur fünf bis zehn Minuten dauerten. Die Analyse zeigte auch einen Infrastrukturwechsel von Cloud-Anbietern zu dedizierten, verkäuferbezogenen Domains und legitimen Cloud-Speichern.
Schadensminderung
Anbieter sollten eine durchgängige kryptografische Signaturverifizierung für alle heruntergeladenen ausführbaren Dateien und Konfigurationsdateien durchsetzen. Organisationen sollten striktes Ziel-Pinning für Aktualisierungsclients implementieren, um Umleitungen zu unautorisierten Domains zu verhindern. Das Einschränken von URI-Schemata innerhalb von In-App-Handlern kann auch helfen, WebDAV-basierte NTLM-Anmeldeinformations-Nötigungsangriffe zu verhindern.
Reaktion
Sicherheitsteams sollten rückblickende Endpoint- und Netzwerksuchen durchführen, die den Zeitraum von April bis Juli 2026 abdecken. Priorisiert werden sollte die Überwachung unsignierter Kindprozesse, die von legitimen Aktualisierungsprogrammen gestartet wurden, und Anzeichen unautorisierter Netzwerkumleitungen. Analysten sollten zwischengespeicherte Lokalkonfigurationsdateien prüfen, anstatt sich ausschließlich auf Live-Überprüfungen von vom Anbieter gehosteten URLs zu verlassen.
Angriffsablauf
Wir aktualisieren diesen Teil noch.
Erkennungen
Verdächtige geplante Aufgabe (über Audit)
Möglicher PowerShell-Ausführungsprozess in verdächtigem Verzeichnis (über cmdline)
Alternative Remotezugriffs-/Verwaltungssoftware (über Prozess_erstellung)
Versuch einer möglichen IP-Lookup-Domainekommunikation (über DNS)
IoCs (HashSha256) zur Erkennung: Untersuchung flüchtiger Manipulationen der Lieferkette
IoCs (SourceIP) zur Erkennung: Untersuchung flüchtiger Manipulationen der Lieferkette
IoCs (DestinationIP) zur Erkennung: Untersuchung flüchtiger Manipulationen der Lieferkette
Erkennung bösartiger AOMEI-Softwareaktualisierungsumleitungen [Proxy]
Erkennung von CROSSROAD- und SHINYROAD-Malware-Aktivität [Windows Sysmon]
Erkennung von bösartigen DLLs und temporären Diensten für die SHINYROAD-Kampagne [Windows-Dateiereignis]
Simulationsausführung
-
Angriffserzählung & Befehle: Ein Angreifer hat erfolgreich einen CROSSROAD-Downloader per Lieferkettenkompromittierung (T1195.002) auf einen Arbeitsplatzrechner gebracht. Um zu verhindern, dass mehrere Instanzen der Backdoor sich gegenseitig beeinträchtigen oder Systeminstabilität verursachen, versucht die Malware, ein spezifisches Mutex zu erstellen. Das Ziel des Angreifers ist es, eine persistente Backdoor (T1547) zu etablieren, um langfristige Kommandokontrolle (C2) und Datenexfiltration zu gewährleisten. Die Simulation wird ein PowerShell-Skript ausführen, das dieses Verhalten nachahmt, indem es genau die globalen und lokalen Mutex-Strings erstellt, die in der Erkennungsregel identifiziert wurden.
-
Regressionstest-Skript:
# CROSSROAD/SHINYROAD-Mutex-Simulationsskript # Dieses Skript simuliert die Erstellung der spezifischen Mutexes, die von der Erkennungsregel anvisiert werden. Write-Host "[*] Starten der Mutex-Simulation..." -ForegroundColor Cyan # 1. Simulieren des Global Mutex (CROSSROAD) try { $globalMutexName = "GlobalF9E6E3C0-E11A-4F85-9944-AF4AD6E05883" Write-Host "[!] Versuch, Global Mutex zu erstellen: $globalMutexName" -ForegroundColor Yellow $globalMutex = New-Object System.Threading.Mutex($true, $globalMutexName) Write-Host "[+] Global Mutex erfolgreich erstellt." -ForegroundColor Green } catch { Write-Error "[X] Erstellung des Global Mutex fehlgeschlagen: $($_.Exception.Message)" } # 2. Simulieren des Local Mutex (SHINYROAD) try { $localMutexName = "Local963d3c60-d406-4ad6-aa1e-dc8e45061ccf" Write-Host "[!] Versuch, Local Mutex zu erstellen: $localMutexName" -ForegroundColor Yellow $localMutex = New-Object System.Threading.Mutex($true, $localMutexName) Write-Host "[+] Local Mutex erfolgreich erstellt." -ForegroundColor Green } catch { Write-Error "[X] Erstellung des Local Mutex fehlgeschlagen: $($_.Exception.Message)" } Write-Host "[*] Mutexes werden für 30 Sekunden gehalten, um Telemetrieerfassung sicherzustellen..." -ForegroundColor Cyan Start-Sleep -Seconds 30 # Säuberung (Manuelle Freigabe wird beim Skriptaustritt gehandhabt, aber explizit ist besser) if ($globalMutex) { $globalMutex.ReleaseMutex() } if ($localMutex) { $localMutex.ReleaseMutex() } Write-Host "[*] Simulation abgeschlossen." -ForegroundColor Cyan -
Säuberungsbefehle:
# Falls das Script unterbrochen wird, führen Sie dies aus, um die Mutexes freizugeben # Hinweis: In PowerShell, wenn der Prozess stirbt, räumt das Betriebssystem normalerweise die Mutex auf. # Dies ist eine Sicherheitsvorkehrung für den Simulationsausführer. Write-Host "[*] Durchführung der Säuberung..." # Kein spezifischer Befehl erforderlich, wenn der Prozess endet, aber wir stellen sicher, dass keine hängenden Handles vorhanden sind.