Und Heloag hat doch keine Freunde, nur einen Master

Kürzlich veröffentlichte Jose Nazario von Arbor Networks eine Analyse des Backdoor-Trojaners Heloag im Security-Blog des Unternehmens, in der er erwähnte, dass das beobachtete Verhalten des Schädlings teilweise auf P2P C&C-Funktionen hinweisen würde. Allerdings hatte Jose ausschließlich eine dynamische Analyse erstellt, und als ich ihn dann kontaktierte, war er sich dessen gar nicht mehr so sicher (vielen Dank auch an Alex Cox, mir die aufgezeichneten Netzwerk-Spuren seines Honeypots zur Verfügung zu stellen). Mein Interesse für P2P-Botnetze (z.B. Stormfucker: Owning the Storm Botnet [MP4 Video]) brachte mich dazu, mir das Ganze näher anzuschauen.

Die von mir analysierten Heloag-Binaries (6ede527bb5aa65eae8049ac955b1018d gedroppt von d9b14a7bc0334458d99e666e553f0ee0 ) wiesen keinerlei P2P C&C-Funktionen auf! Stattdessen kommuniziert das Botnetz über ein eher allgemeines TCP-Protokoll, das die folgenden Kommandotypen unterstützt (codiert als erstes Byte des Pakets):

  1. Per DDoS einen anderen Host angreifen, und zwar mit unterschiedlichen Methoden:
    • TCP-DDoS, basierend auf connect(..)(sendet keine Daten)
    • UDP-DDoS, basierend auf sendto(..) (sendet willkürlich Daten)
    • HTTP-DDoS anfordern / mit User-Agent „helloAgent“, basierend auf InternetOpenUrlA
    • HTTP-DDoS Links crawlen von / mit User-Agent „Google page“
  2. URL mit bis zu 0xA4 Bytes downloaden und ausführen, mit Nullen aufgefüllt
  3. Aktuellen Computernamen senden
  4. Ausführung des aktuellen DDoS-Befehls stoppen
  5. Verbindung zu aktuellem Server trennen und mit neuem C&C-Server verbinden

Assembler-Code für Funktion 4

Dies bedeutet, dass trotz der Beobachtung einer Vielzahl von C&C-Servern während unserer dynamischen Analyse es sich lediglich um eine bestimmte Übergabemethode zu einem anderen C&C-Server handelt, die zum Lastenausgleich oder zur Vermietung von Botnetzen genutzt werden kann. Da der Bot zu jedem Zeitpunkt immer nur mit einem Server verbunden ist, wird dadurch die Fehlertoleranz nicht wesentlich reduziert (puh!).

Im Hinblick auf die Urheberschaft von Malware handelt es sich dennoch um ein interessantes Malware-Exemplar. Es fällt sofort auf, dass, während für die meisten Befehle jeweils ein Kontroll-Byte existiert, sämtliche DDoS-Befehle in demselben Byte codiert sind. Die zusätzliche Payload dieser Befehle steuert dann, welche DDoS-Attacke wann und wo ausgeführt wird. Anstatt einen Byte-Typ wie für Kontroll-Bytes zu verwenden, nutzt dieser Code in der Payload verschiedene boolesche Bytes, um die DDoS-Typen zu steuern. Außerdem macht der Code in Zusammenhang mit DDoS starken Gebrauch von C++std:;Strings, während der übrige Main-Code die Funktion wsprintf zur String-Steuerung benutzt. Es hat den Anschein, als ob dieses Programm von zwei verschiedenen Autoren in Zusammenarbeit geschrieben worden wäre oder zumindest, als ob einer einiges Quellmaterial des anderen gekauft hätte.

Dieser Schadcode stammt mit hoher Wahrscheinlichkeit aus China. Zunächst weist die Verwendung von wsprintf auf geringe Kenntnis der in westlichen Pfadnamen üblichen Buchstaben hin, was bei aus westlichen Ländern stammenden Schadprogrammen nur selten beobachtet wird. Ferner befindet sich in der Binärdatei eine chinesische hart codierte IP-Adresse, die nicht durch DDoS angegriffen werden kann, ganz egal, welcher Befehl dem Bot gegeben wird (und dies wurde nach der DNS-Auflösung überprüft).

Ähnliche Beiträge

Schreibe einen Kommentar

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