SWITCH Security-Blog

SWITCH-CERT IT-Security Blog


Einführung in die Anti-Malware-Analyse – Teil 3: Anti-VM

Im zweiten Teil dieser mehrteiligen Serie definierten wir den Begriff Ausführbare Datei und zeigten, was hinter Anti-Debugging steckt. Die Analyse der Malware war dynamisch, das heisst, der bösartige Code wurde effektiv ausgeführt – und das Analysesystem mit grosser Wahrscheinlichkeit infiziert. Wäre es daher nicht praktisch, die Analyse in einer virtuellen Umgebung durchzuführen? Mit einem Knopfdruck ist der saubere Zustand wieder hergestellt. Eine Idee, die auf der Hand liegt. Entsprechend haben sich die Autoren bösartiger Software dazu Gedanken gemacht und eine Technik entwickelt, diesen Umstand auszunutzen – Anti-VM: Läuft die Malware in einer virtuellen Maschine, so gehe davon aus, dass es sich um einen Malware-Analysten handelt und mache nichts böses.

Bevor wir darauf eingehen – lohnt es sich überhaupt das anzuschauen? Werden nicht bald alle Maschinen virtuell laufen? Schön möglich, aber im Moment nicht und die Anti-VM-Technik wird erstaunlich oft angewandt. Gemäss einer Untersuchung von Qualys [1] (im Jahr 2012) implementieren 90% der untersuchten Malwaresamples (4 Millionen Stück) mindestens eine Anti-Malware-Technik – mit über 80% bei weitem am häufigsten Anti-VM.

Anti-Malware Techniken. Quelle: Qualys 2012

Anti-Malware Techniken. Quelle: Qualys 2012

Notabene: 2.9 der 4 Millionen untersuchten Malwaresamples greifen auf eine Anti-VM-Methode namens IN zurück – weshalb wir uns in diesem Artikel hauptsächlich damit beschäftigen.

Virtuelle Maschinen unterscheiden sich von physikalischen Maschinen. Diese Unterschiede können offensichtlich sein: Installierte Software (VMware-Tools), Laufende Prozesse (vmtoolsd.exe), Herstellerkennung der (virtuellen) Netzwerkkarte (00:0c:29:xx:xx:xx), Harddisk-Bezeichnungen etc. Aber einige Unterschiede sind erst in den Tiefen des Betriebssystems zu finden. Die erste Detektion einer virtuellen Umgebung auf nicht-triviale Art wird Joanna Rutkowska von Invisible Things Lab attributiert. Ihr Code aus dem Jahr 2004 wird häufig wie folgt zitiert[2]:

int swallow_redpill () {
   unsigned char m[2+4], rpill[] = "\x0f\x01\x0d\x00\x00\x00\x00\xc3";
   *((unsigned*)&rpill[3]) = (unsigned)m;
   ((void(*)())&rpill)();
   return (m[5]>0xd0) ? 1 : 0;
}

…auch bekannt als “Red Pill”. Continue reading


Einführung in die Anti-Malware-Analyse – Teil 2: Anti-Debugging

Im ersten Teil dieser mehrteiligen Serie führten wir in die Grundprinzipien von Maschinen- und Assemblerbefehlen ein und zeigten, was hinter Anti-Disassembly steckt. Es wurde kein Code ausgeführt, weshalb wir von statischer Analyse sprachen. Heute beschäftigen wir uns mit der Störung der dynamischen Analyse, im speziellen mit Debugging, und daher heisst diese Folge Anti-Debugging.

Was ist eigentlich eine ausführbare Datei? Wie erkennt ein Betriebssystem, dass abzuarbeitende Maschinenbefehle vorliegen und es sich nicht um ein Bild handelt? Das hat etwas mit dieser Folge zu tun? Ganz bestimmt.

Es ist nicht einfach, eine geschlossene Definition für den Begriff Ausführbare Datei zu geben [1], da je nach Situation unterschiedliche Konzepte greifen. Eine Datei mit der Endung .bat (Batchdatei) wird von einem Windows-Betriebssystem als Kommandozeilen-Skript interpretiert – und ausgeführt. Eine Datei mit keiner Endung aber bestimmten Bytes am Anfang wird wiederum als PE-Datei erkannt – und ausgeführt. PE-Dateien sind den meisten PC-Benutzern bekannt: Diese Dateien haben typischerweise die Endung .exe.

Continue reading


Einführung in die Anti-Malware-Analyse – Teil 1: Anti-Disassembly

In dieser mehrteiligen Serie möchten wir Ihnen Techniken vorstellen, die das Leben eines Malwareanalysten erschweren, sprich abwechslungsreich und spannend machen. Im ersten Teil behandeln wir Anti-Disassembly und führen in die Thematik ein.

Warum macht ein Computer eigentlich, was er macht? Und was hat das mit dem Thema dieser Reihe zu tun? Zwei zentrale Fragen, welche im Folgenden beantwortet werden.

Entwickler erstellen Computerprogramme meist in einer Sprache, die intuitiv verständlich ist. Man bezeichnet das Ergebnis dieser Schreibbemühungen als Quellcode.

	10 REM Hello World in BASIC
	20 PRINT "Hello World!"

Viel kann der Computer (oder genauer gesagt die CPU) damit nicht anfangen. Der Quellcode muss in eine Sprache übersetzt werden, welche die CPU versteht – in eine Abfolge von Maschinenbefehlen.

	6A 40 68 00 30 40 00 68 17 30 40 00 6A 00 E8 07 00 00 00 [...] 
	48 65 6C 6C 6F 20 57 6F 72 6C 64 21 00

Diese Maschinenbefehle sind eher schwierig zu lesen, aber üblicherweise ist dies das einzige, was den Malwareanalysten zur Verfügung steht. Continue reading