- Malware prüft die Existenz von Hardware wie eines CPU-Lüfters, um die Ausführung in virtuellen Umgebungen zu vermeiden
- Informationen zum CPU-Lüfter lassen sich über die WMI-Klasse Win32_Fan abrufen; diese Daten sind im SMBIOS gespeichert
- Um in Xen benutzerdefinierte SMBIOS-Daten einzufügen, sind ein Patch und eine separate Konfiguration nötig; dabei müssen sowohl die Tabellen Cooling Device (Typ 27) als auch Temperature Probe (Typ 28) konfiguriert werden
- In QEMU/KVM lassen sich benutzerdefinierte SMBIOS-Daten ohne zusätzlichen Patch einfach per
-smbios-Option anwenden
- Dadurch kann man der virtuellen Maschine vorgaukeln, dass ein CPU-Lüfter vorhanden ist, um die Erkennung durch Malware zu umgehen
Warum macht man so etwas?
- Einige Malware-Programme prüfen, ob sie in einer virtuellen Umgebung laufen, indem sie die Existenz bestimmter Hardware (z. B. eines CPU-Lüfters) kontrollieren
- Sie untersuchen Hardware über WMI-Klassen wie
Win32_Fan; fehlen diese Informationen, stufen sie das System als virtuelle Maschine ein und vermeiden die Ausführung
- Ziel ist es, zu verhindern, dass Analysten die Malware analysieren können
- Es gibt verschiedene WMI-Klassen wie
Win32_CacheMemory und Win32_VoltageProbe, aber dieser Artikel konzentriert sich auf den CPU-Lüfter
Wie erkennt ein Computer, ob ein CPU-Lüfter vorhanden ist?
- Der Computer liest SMBIOS-Informationen und erkennt daran die Existenz eines Kühlgeräts (CPU-Lüfters)
- Die
Win32_Fan-Instanz wird von cimwin32.dll bereitgestellt, und diese DLL liest Lüfterinformationen aus dem SMBIOS-Eintrag vom Typ 27
- Auch DLL-Hooking wäre möglich, aber die direkte Manipulation von SMBIOS ist der bessere Ansatz
SMBIOS Typ 27
- SMBIOS Typ 27 bedeutet "Cooling Device"
- Mit dem Dienstprogramm
dmidecode lassen sich die Cooling-Device-Daten im SMBIOS direkt prüfen
- Beispiel:
- Type: Chip Fan
- Status: OK
- Description: CPU Fan
- Nominal Speed: 5600 rpm usw.
So richtet man benutzerdefinierte SMBIOS-Daten in Xen ein
- In Xen kann man mit der Option
smbios_firmware in der Domain-Konfigurationsdatei SMBIOS-Daten im Binärformat direkt angeben
- Dazu erstellt man eine Datei
smbios.bin und fügt die Cooling-Device-Daten (Typ 27) ein
- Die Größe der SMBIOS-Struktur (z. B. 24 Byte) muss als 32-Bit-Little-Endian-Integer vorangestellt werden
Problem: Einschränkungen beim Überschreiben von Strukturen
- Xen erlaubt das Überschreiben nur für die Strukturtypen 0, 1, 2, 3, 11, 22, 39
- Typ 27 ist standardmäßig nicht erlaubt, daher ist ein Patch im Quellcode nötig
- Auch im Xen-Entwicklerforum wurde ein entsprechender Patch vorgeschlagen, offiziell aber nicht übernommen (Patch anwenden und neu bauen erforderlich)
Typ 28 wird ebenfalls benötigt
- Cooling Device (Typ 27) ist mit Temperature Probe (Typ 28) verknüpft
- Fehlt im SMBIOS ein Eintrag vom Typ 28, wird die Klasse
Win32_Fan nicht korrekt angezeigt
- Für eine korrekte Erkennung muss man die Daten vom Typ 28 des Host-Systems auslesen und zu
smbios.bin hinzufügen
Endgültige Struktur von smbios.bin
- Enthält sowohl Daten von Typ 27 als auch von Typ 28
- Vor jeder Struktur werden Größeninformationen im Little-Endian-Format eingefügt
- Beispiel:
18 00 00 00 ... (Typ 27) ... 29 00 00 00 ... (Typ 28) ...
Anwendung und Prüfung in Xen
- Nach dem Starten der Windows-VM mit dem Befehl zur Domain-Erstellung prüft man in WMI, ob die Klasse
Win32_Fan korrekt erkannt wird
- Die Anzeige
Description: Cooling Device, Status: OK bestätigt, dass der CPU-Lüfter erfolgreich erkannt wurde
SMBIOS-Daten in QEMU/KVM setzen
- In QEMU/KVM lassen sich benutzerdefinierte SMBIOS-Daten einfach mit der Option
-smbios file=Pfad setzen
- Dabei werden rohe Daten ohne Strukturgrößeninformationen verwendet
- Man kann auch direkt die SMBIOS-Daten des Hosts verwenden
Referenzmaterial
- Dokumentation zur Xen-Domain-Konfigurationsdatei, Setup-Notizen von mcnewton, Archiv des abgelehnten Xen-Patches, System Management BIOS Reference, QEMU Anti Detection Patch usw.
1 Kommentare
Hacker-News-Kommentare
Als weitere Anti-Malware-Methode wurde erwähnt, dass man einen passiv gekühlten PC kaufen kann; auch das Einstellen einer russischen Tastatur sei ein Tipp, um betrügerische Malware abzuhalten, siehe zugehöriger Link
Ich nutze tatsächlich einen passiv gekühlten Linux-PC vom Typ Streacom FC8 Evo und eine russische Tastatur, aber laut
dmidecodesind weiterhin Informationen zu Kühlgeräten vorhanden und Kühlhardware wird tatsächlich erkannt; über Sensordaten lassen sich auch Temperaturwerte prüfenAuch bei einem passiv gekühlten PC bleiben auf dem Mainboard in der Regel Lüfter-Header vorhanden, daher dürfte es keinen großen Unterschied machen, selbst wenn nichts tatsächlich angeschlossen ist
Es wurde angemerkt, man solle keine Ausdrücke wie „smol pp“ verwenden, und darauf hingewiesen, dass damit Spott über den Körper in die Sprache einfließt
In meiner Stadt fährt tatsächlich jemand mit dem Wunschkennzeichen „SML PP“ herum, warum, weiß ich nicht
Es wurde die Formulierung „unsere Sprache“ benutzt, aber zugleich sei unklar, wer mit „wir“ überhaupt gemeint ist, wenn jemand im Kommentarbereich eines Blogs davon spricht
Die Ansicht, dass es die Sicherheit erhöhen und Forschenden helfen könnte, wenn ein Betriebssystem wie eine virtuelle Maschine aussieht: Wer einen nicht virtualisierten Zugriff wolle, müsse dafür ausdrücklich eine Berechtigung erhalten, und so könnte Malware zur Vermeidung von Analysen durch Forschende womöglich auch normale Nutzer nicht mehr ins Visier nehmen; am Ende würden also alle außer den Malware-Autoren profitieren
Nicht ein normales Betriebssystem sollte wie eine VM aussehen, sondern vielmehr sollte eine virtuelle Maschine gar nicht bemerken, dass sie virtualisiert ist; IBMs LPAR-Systeme sollen so funktionieren
In so einem Modell würden allerdings auch Anti-Cheat-Softwarefirmen verlieren; ich möchte zwar genau wissen, wo meine Software läuft, aber viele Multiplayer-Spieler hassen Cheater noch mehr als Betrügereien, weshalb sich realistisch wohl nur schwer etwas ändern dürfte
In der Welt der mobilen Entwicklung sei ein solcher Rahmen ohnehin bereits Realität
Ich habe bislang noch nie gesehen, dass SMBIOS-Beschreibungen auf Consumer-Mainboards wirklich zur echten Hardware passen; Malware, die so etwas prüft, könnte zwar auf 50 % echter Hardware scheitern, aber wenn sie dafür 100 % der VMs oder Debugger zuverlässig meidet, lohnt sich das aus Sicht der Malware trotzdem; trotzdem wäre eine Prüfung über Zeitmessung vermutlich verlässlicher als dieser Ansatz
Dass SMBIOS-Beschreibungen nicht zur tatsächlichen Hardware passen, sei besonders bei günstigen chinesischen Boxen stark ausgeprägt; nicht ausgefüllte Werte wie „to be filled in by OEM“ sehe man in echten Live-BIOS-Images beim Codieren häufig, und allein das sei schon absurd genug
Malware ist ebenfalls voller Bugs; wie bei früheren Fehlern im Netzwerkcode, durch die sich Viren nur mit halber der beabsichtigten Geschwindigkeit verbreiteten, kann Malware auch dann enormen Schaden anrichten, wenn sie längst nicht alle Geräte infiziert
Mich würde inzwischen interessieren, wie Linux Lüfter überhaupt erkennt, ob über ACPI oder EFI; auf meinen Geräten werden Lüfter und Sensoren größtenteils korrekt erkannt
Ich frage mich, ob diese SMBIOS-Prüfung tatsächlich von realer Malware verwendet wird oder nur in von Forschenden erstellten Samples vorkommt
Die Tricks, mit denen Malware über APIs die Analyse erschweren will, mögen niedlich wirken, aber die meisten solchen API-Aufrufe lassen sich in der statischen Analyse leicht erkennen, und wenn das Binärprogramm nicht obfuskiert ist, ist das eher kontraproduktiv; echte, zielgerichtete Programme werden meist mit Signaturen vertrauenswürdiger CAs verteilt und lassen sich in der Sicherheitsanalyse daher gut als verdächtiges Verhalten erkennen; ich habe als Junior sogar einmal mit Regex-Mustern genau solche API-Nutzung herausgefiltert, und das war recht effektiv, um massenhaft verbreitete Standard-Malware zu erkennen
Inzwischen signiert auch Malware recht häufig Dateien; die Erwartung, Malware-Anbieter würden Binärdateien nicht signieren, trifft nicht mehr zu. Gestohlene Code-Signing-Zertifikate sind verbreitet, und Microsoft zögert oft mit dem Widerruf, weil sonst Software bestehender Kunden beschädigt werden könnte. Malware nutzt außerdem oft verwundbare Treiber, um in den Kernel einzudringen. Daher erregt ein verdächtiges kleines Binärprogramm mit WMI-Aufrufen mehr Aufmerksamkeit als ein Overclocking-Tool voller Schwachstellen, das dieselben Abfragen stellt. In der Praxis soll diese Methode weniger der Umgehung von Erkennung dienen als vielmehr verhindern, dass der Malware-Payload auf dem PC eines Analysten aktiviert wird; wird etwas erkannt, wird kein zweiter Payload nachgeladen und das C&C-Verhalten, das echte Angriffe auslösen würde, bleibt ausgesetzt
Aus Sicherheitssicht wäre es vielleicht besser, sämtliche Software in VMs laufen zu lassen
Es ist auch fragwürdig, wenn Antivirus nur per statischer Analyse einschätzt, ob etwas Malware ist; dann könnte man genauso gut gleich nur per Whitelist vertrauenswürdige Software zulassen und alles andere als Malware behandeln, das käme aufs Gleiche hinaus
Die Realität ist, dass Firmen wie CrowdStrike offiziell signierte, schlampige Software auf Kernel-Ebene laufen lassen können und alle Systemaufrufe machen dürfen, ohne dass es jemanden kümmert. Ob VM oder nicht spielt kaum eine Rolle; problematisch ist vielmehr, dass ungeprüfter Code und ungeprüfte Releases direkt in Produktion ausgerollt werden und selbst dann niemand wirklich Verantwortung übernimmt, wenn dadurch die Welt stillsteht, Flüge verspätet sind oder kritische Infrastruktur ausfällt. Der Vorwurf lautet, dass legitime Unternehmen mitunter größeren Schaden anrichten können als Hacker oder staatliche Angreifer; auch der Vorfall um das
xz-Utility sei ein Sicherheitsereignis von einer Größenordnung, die Vergleiche mit SolarWinds oder ClownStrike zulässtIch habe gesehen, wie ein Freund aus der Infosec-Branche den Großteil seiner Zeit darauf verwendet, Malware-Honeypots zu bauen, die echter Hardware vollkommen ähneln; von Windows-XP-basierten Thermostaten über Siemens-PLC-Controller bis hin zu Banking-Desktops richtet er unglaublich viele unterschiedliche Geräte extrem detailgetreu ein
Das erinnert mich daran, dass man beim Einrichten eines Hackintosh unbedingt ein passendes SMBIOS brauchte; viele eher obskure PC-APIs wurden in den letzten Jahrzehnten eingeführt und werden oft verwendet, um zu testen, wie gut Virtualisierungssoftware oder Malware solche Details abbildet; der nächste Schritt wäre eine Temperatursensor-Simulation, die sich passend zur tatsächlichen CPU-Last dynamisch verändert
Laut Mitre ATT&CK T1497.001 (VM Detection) ist die SMBIOS-Prüfung ein bekannter Vektor; ich habe selbst experimentiert und konnte das Netzteil mit
HotReplaceable=YesundStatus=OKso einstellen, dass das System wie ein 5.000-Dollar-Bare-Metal-Server erscheint; verwendet wurde der Befehlpip install dmigendanachdmigen -o smbios.bin --type0 vendor="American Megatrends",version="F.1" --type1 manufacturer="Dell Inc.",product="PowerEdge T630" --type39 name="PSU1",location="Bay 1",status=3,hotreplaceable=1