Im Praxistest: Kann Malware eine Sandbox umgehen?

Eine Untersuchung verschiedener Sandboxes zur Malware-Erkennung hat gezeigt, dass in der Qualität der untersuchten Produkte Verbesserungsbedarf besteht.

Automatisierte Malware-Erkennung durch Verhaltensanalyse mittels Sandboxes ist heute eine wichtige Ergänzung herkömmlicher Antivirus-Software. Doch auch die Malware-Entwicklung steht nicht still und bringt beständig neue Techniken hervor, die das schädliche Verhalten der Sandbox gegenüber verschleiern.

Eine Sandbox ist in diesem Kontext ein isoliert betriebenes System zur Klassifikation unbekannter Software. Es befindet sich meist virtualisiert in einer Cloud. Sandbox-basierte Malware-Erkennung platziert unbekannte Software in dieser Sandbox und führt diese dort aus. Während der Ausführung protokolliert die Sandbox die Funktionsaufrufe der unbekannten Software und analysiert deren Verhalten. Anschließend entscheidet die Sandbox anhand bekannter schädlicher Verhaltensmuster, ob es sich bei dieser Software um Malware handelt.

Erkennt Malware anhand untypischer Systemeigenschaften, dass sie in einer Sandbox ausgeführt wird, umgeht sie die Erkennung durch harmloses Verhalten.

Die Qualität einer Sandbox lässt sich also dadurch messen, inwieweit sie untypische Systemeigenschaften verschleiert. Das haben wir mittels eines Testprogramms untersucht, das verschiedene Techniken der Sandbox-Erkennung implementiert.

Prüfmethodik und Ergebnissauszug

Anzeichen für Virtualisierung

Gängige Virtualisierungsprodukte (Hypervisors) sind in der Standardkonfiguration nicht darauf getrimmt, ihre Präsenz gegenüber ihrer Gastsysteme zu verschleiern. Dieses Kapitel enthält Erkennungstechniken um Rückstände des Hypervisors erkennen.

Untersucht wurden CPU-Eigenschaften, Festplatten-, RAM- sowie Displaygröße und Computername. Ein Hypervisor hat dabei prinzipiell die Möglichkeit, virtuellen Maschinen ein anderes CPU-Modell vorzugaukeln.

Testergebnisse dieser Kategorie sind unter anderem:

  • Hypervisorspezifische CPU-Namen wie beispielsweise „Intel Xeon E3-12xx v2 (Ivy Bridge)“
  • Standardwerte oder nur leicht angepasste Werte im Hypervisoranbieterfeld (VBoxVBoxVBox, HVMKM)
  • Untypische RAM-Größen (3.5GB, 1.95GB, 2.5GB)
  • Künstliche Desktop-Auflösungen sowie Festplattengrößen
  • Konstant bleibender Computername
  • Vergleichsweise geringe Anzahl verfügbarer CPU-Kerne

Desweiteren unterscheidet sich die Ausführungsdauer der CPUID-Instruktion in virtualisierten Systemen deutlich von bare-metal Systemen, da sie beim Aufruf in einer virtuellen Maschine einen Hypervisor Interrupt verursacht – also die CPU den Kontrollfluss an den Hypervisor übergibt und einen Context Switch verursacht. Diese CPUID-Ausführungsdauer wird in CPU-Zyklen gemessen (RDTSC-Instruktion) und anschließend mit einem Schwellwert verglichen.

Ergebnis: Diese Erkennungstechnik funktionierte bei vier von fünf Sandboxes zuverlässig, um zwischen bare-metal, virtualisierten und emulierten Systemen zu unterscheiden.

Indizien für ein künstlich erzeugtes System

Durch reguläre Nutzung eines Systems entstehen auf diesem oft Gebrauchsartefakte wie zuletzt geöffnete Dateien, installierte Windows-Updates oder eine wachsende DNS Cache. Die Abwesenheit solcher Gebrauchsartefakte ist ein Indiz dafür, dass es sich bei einem System um ein künstliches Setup handelt, das nicht benutzt oder oft zurückgesetzt wird.

Ergebnis: Alle getesteten Sandboxes offenbaren in diesem Bereich Nachholbedarf.

Virtuelle Hardware

Virtualisierungsprodukte (Hypervisors) implementieren nur einen Bruchteil der verfügbaren Hardware, die sie ihren Gastsystemen zur Verfügung stellen. Erkennungstechniken dieser Kategorie suchen Hardware, die mit sehr hoher Wahrscheinlichkeit einem Hypervisor zugeordnet werden kann.

Beispiele für virtuelle Hardware:

  • Netzwerkadapter mit hypervisorspezifischer MAC-Addresse
  • VirtualBox Graphics Adapter
  • VMware VMCI Bus Device
  • QXL video card device
  • QEMU Standard VGA device

Beispiele für physische Hardware:

  • Intel HD Graphics bei Core-i Prozessoren
  • Trusted Platform Modules (TPM)

Ergebnis: Vier von fünf getesteten Sandboxes konnten über bekannte virtuelle Hardware klassifiziert werden.

Beschleunigung des Sleep-Aufrufs

Um der großen Anzahl an potentieller Malware Herr zu werden, ist die Ausführungsdauer, die eine Sandbox auf ein Sample verwendet, zeitlich auf wenige Minuten begrenzt.

Der Aufruf der Sleep-Funktion (aus kernel32.dll) unterbricht die Ausführung des aktuellen Threads vorübergehend. Daher wird sie gerne von Malware verwendet, um bösartiges Verhalten zu verzögern. In diesem Fall greift das Timeout der Sandbox vor dem bösartigen Verhalten und die Malware wird nicht als solche erkannt.

Sandboxes erkennen jedoch den Aufruf der Sleep-Funktion, ersetzen den Parameter, der für die Dauer zuständig ist durch einen kleineren Wert und beschleunigen somit diesen Aufruf, um das obige Szenario zu verhindern.

Hat die Malware Zugriff auf einen externen Zeitgeber wie beispielsweise einen NTP-Server, kann sie diese Beschleunigung erkennen und damit feststellen, dass sie sich in einer Sandbox befindet.

Ergebnis: Eine Beschleunigung der Sleep-Funktion konnte in keiner der fünf Sandboxes festgestellt werden, was zum Teil aber auch daran liegt, dass die Sandbox keine Internetverbindung hat und somit auch keinen NTP-Server erreichen kann.

Inline Hooks, Belege für Verhaltensanalyse

Inline Hooking ist eine weit verbreitete Technik, um Funktionsaufrufe abzufangen oder zu protokollieren. Dabei  wird der Kontrollfluss der Funktion durch gezieltes Einfügen von Sprungbefehlen in den Code verändert. Diese Sprungbefehle zeigen auf Code, der dann beispielsweise den Funktionsaufruf protokolliert und anschließend zur ursprünglichen Funktion zurückspringt.

Wird diese Art der Verhaltensanalyse im User space implementiert, wo auch das Testprogramm läuft, werden die Sprungbefehle Teil des ausgeführten Codes. Das bedeutet, ein Programm kann selbst gezielt nach Sprungbefehlen von Inline Hooking suchen. Sprungbefehle am Anfang von Funktionen der Windows API, die dort nicht erwartet werden, offenbaren eine Manipulation des Programmablaufs.

Ergebnis: Drei von fünf Sandboxes konnten durch diese Technik erkannt werden.

Umgebung der Sandbox

Erkennungstechniken dieser Kategorie untersuchen die Umgebung des Systems auf Verfügbarkeit von WLAN-Netzwerken und Bluetooth-Geräten, welche in virtualisierten Umgebungen untypisch sind und somit sicherstellen, dass das Testprogramm im Büro- oder Privatumfeld ausgeführt wird.

Im Unternehmensumfeld ist zudem noch interessant, ob das System einer Domain zugeordnet ist. Dies wird zudem verifiziert, indem die Erreichbarkeit des Domain Controllers sichergestellt wird.

Ergebnis:

  • Systeme keinen Domains zugeordnet
  • Stationäre Systeme ohne Akku (keine Notebooks)
  • Eine von fünf Sandboxes sieht WLAN-Netzwerke

Fazit

Die durchgeführten Tests zeigen, dass die Erkennung einer Sandbox vergleichsweise einfach ist:

  • Hypervisors kaum gehärtet
  • Gebrauchsartefakte selten
  • Inline Hooking weit verbreitet
  • Bekannte virtuelle Hardware

Jedoch bestehen große Unterschiede zwischen den Virtualisierungs-Technologien und der technischen Umsetzung der Verhaltensanalyse, was eine Diversifikation bedeutet. Desweiteren finden sich in den meisten Sandboxes einige Abnutzungsartefakte, wie zuletzt geöffnete Dateien.

Abgesehen von den direkten und indirekten Rückständen der Virtualisierung bleibt es weiterhin eine Herausforderung, den Unterschied zwischen den verhältnismäßig generisch konfigurierten Sandboxes und echten Endpunkt-Systemen zu minimieren. Diesem Problem kann man damit begegnen, indem das Verhalten von Software direkt auf dem Endpunkt-System analysiert wird, wo dieser Unterschied logischerweise nicht besteht.

Aus diesem Grund bieten Sandboxes auch keine Chance gegen zielgerichtete Angriffe, die die Ausführung von Schadcode von der Zugehörigkeit einer bestimmten Domain abhängig machen (keyed payloads).

Stand heute ist die Verwendung von Sandboxes trotzdem zu empfehlen, um einem Großteil der täglichen Malware-Flut entgegenzutreten, der gegen statische Analyse resistent ist, aber dessen Sandbox-Erkennung noch nicht besonders hoch entwickelt ist.

Um ein Wundermittel, wie manchmal beworben, handelt es sich bei Sandbox-basierter Malware-Erkennung aber definitiv nicht.

2 Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

CAPTCHA *