Wie erkennt und umgeht Malware Analyse-Sandboxes, und wie wirkst du dem entgegen?
Kurzantwort
Sandbox-bewusste Malware prüft, ob sie beobachtet wird, bevor sie sich fehlverhält. Sie sucht nach VM- und Hypervisor-Artefakten (Treiber, MAC-Präfixe, Registry-Schlüssel, CPUID), nach Analyse-Werkzeugen und Debuggern (Prozessnamen, IsDebuggerPresent, Timing des Single-Steppings) und nach Anzeichen eines echten Benutzers (wenige Prozesse, keine zuletzt verwendeten Dokumente, keine Mausbewegung, niedrige Uptime, kleine Festplatte). Sie kann mit langen Sleeps verzögern oder nur an einem bestimmten Datum, in einer bestimmten Sprache oder Domäne auslösen. Analysten wirken dem entgegen, indem sie die VM so härten, dass sie echt aussieht, die Prüfungen herauspatchen, Sleeps vorspulen, Benutzeraktivität simulieren und das Verhalten mit statischem Disassembly bestätigen.
Dynamische Analyse ist nur nützlich, wenn die Malware ihren bösartigen Code tatsächlich ausführt, während du zusiehst. Interviewer fragen das, weil moderne Samples davon ausgehen, in einer Sandbox detoniert zu werden, und ihr Verhalten verbergen, wenn sie eine erkennen. Das Katz-und-Maus-Spiel hier zu verstehen, ist Kern des Jobs.
Was die Malware prüft
- Umgebungsartefakte. VM- und Hypervisor-Fingerabdrücke: VMware/VirtualBox-Treiber und -Registry-Schlüssel, bekannte MAC-Adress-Präfixe, das
CPUID-Hypervisor-Bit, BIOS-Strings sowie kleine Festplatte oder wenig RAM. Vorhandensein von Analyse-Werkzeugen (Procmon, Wireshark, x64dbg) anhand von Prozess- oder Fensternamen. - Debugger-Erkennung.
IsDebuggerPresent,CheckRemoteDebuggerPresent, PEB-Flags, Timing-Prüfungen, die die Verlangsamung durch Single-Stepping bemerken, und exception-basierte Tricks. - Echt-Benutzer-Signale. Sandboxes wirken steril: wenige laufende Prozesse, keine zuletzt verwendeten Dokumente, Standard-Benutzernamen, keine Mausbewegung, niedrige Uptime und ein sauberer Browserverlauf. Malware, die eine makellose Maschine sieht, nimmt an, dass sie analysiert wird.
- Logikbomben und Stalling. Lange
Sleep-Aufrufe oder Busy-Loops, um das Analysefenster der Sandbox zu überdauern; Trigger, die an ein bestimmtes Datum, Systemsprache, Tastaturlayout oder eine Domäne gebunden sind, sodass sie nur auf dem beabsichtigten Ziel auslösen.
Wie Analysten dem entgegenwirken
Du lässt die VM bewohnt aussehen: installiere gängige Software, befülle Dokumente und Verlauf, simuliere Maus- und Tastaturaktivität, setze eine realistische Uptime und entferne offensichtliche Werkzeug-Artefakte. In einem Debugger patchst du die Anti-Debug-Prüfungen heraus oder hookst die API, damit sie lügt, und du spulst Sleeps vor, indem du Sleep/NtDelayExecution hookst. Entscheidend ist, dass du auf statisches Disassembly zurückgreifst, um die Evasion-Logik und Zielbedingungen zu lesen, die dynamisch nie auslösen.
Eine starke Antwort rahmt es als Wettrüsten und betont, dass statische und dynamische Analyse die toten Winkel der jeweils anderen abdecken.
Wahrscheinliche Anschlussfragen
- Wie würdest du eine Analyse-VM wie die Workstation eines echten Benutzers aussehen lassen?
- Was ist Sleep-basiertes Stalling und wie besiegst du es?
- Wie kann statische Analyse Evasion-Logik aufdecken, die dynamisch nie auslöst?