Um sich der Botnet Problematik zu nähern, ist das Verständnis über deren Arbeitsweise unerlässlich.  Genau wie der professionelle Aufbau eines funktionierenden Netzes, gestaltet sich auch der Aufbau eines Bots. Die Unterteilung in die entsprechenden Module Kontrollebene, Kommunikationsebene, Infektionsebene und Nutzdaten ist ein Prinzip in Hinsicht auf Erweiterbarkeit und Flexibilität der heutigen fortgeschrittenen Bots.

Im weiteren Artikel wollen wir näher auf die Funktionsweise und Aufbau der Bots, hinsichtlich dem Einsatz neuer Technologien und Sicherungsmaßnahmen zum Zwecke der Tarnung und besseren Kontrolle, eingehen.
Kontrollebene
Eines der elementaren Funktionen ist die Steuerbarkeit der Bots durch den Master. Dieser Master setzt Kommandos beim ausführenden Empfänger ab und sorgt für ständige Updates, die die Stabilität und zugleich den Funktionsumfang des installierten Bots stetig erweitert.
Kommunikation / Textbasiert & XML
Unlängst haben Botnetbetreiber erkannt, dass eine unkomplizierte Kommunikation mit den “Slaves” (Bots) durch textbasierte Kommandos realisiert werden kann. Neue Protokollversionen- und arten werden auf textbasierte Kommunikationswege aufgebaut. Hierbei kommen ganz besonders XML und HTTP zum Vorschein, da diese vielseitig einsetzbar und flexibel gehandhabt werden können.
XML wird vorzugsweise eingesetzt, nicht zuletzt, weil diese Auszeichnungssprache sich hervorragend für die strukturelle Ablage von Informationen eignet. Sie kann von den einfachsten Parsern gelesen und interpretiert werden. XML kann zudem plattformunabhängig eingesetzt werden. Interessant ist dies natürlich für Botnet Betreiber, da diese mit Einsatz dieser Kommunikationsform nicht mehr auf bestimmte Plattformen beschränkt sind.
Verschlüsselung & Digitale Signaturen
Durch eine offene, textbasierte Kommunikation ist es für Botnet Betreiber unerlässlich, ihre Informationen zu schützen, z.B. durch digitale Signaturen. Das untere Bespiel zeigt eine Signatur:

Diese lokal gespeicherte XML Konfiguration kann vom Botnet Betreiber mit einfachen Mitteln aktualisiert oder ersetzt werden. Für eine Erneuerung der Signaturkennung ist es lediglich nötig, die XSD-Datei also die Definitionsdatei des XML Schemas auszutauschen. Der Body braucht hierbei nicht manuell verändert zu werden. Die Konfigurationsdatei erkennt die vorhandenen Muster und füllt die Attribute in den <> selbstständig aus.
Unabhängige Kommunikation
Durch XML eröffnen sich neue Wege und Instanzen, die die Bots nicht nur als deren vorgesehene Funktion erscheinen lassen, sondern auch zu vielseitigen Werkzeugen in den Händen der Kriminellen macht. Durch eine plattformunabhängige und barrierefreie Kommunikation muss der Controller auf der Kontrollebene nichts über die Kommunikationsstrukturen innerhalb der lokalen Instanz wissen. Der Master verweist hierbei auf die XML Spezifikation und hat alle Möglichkeiten, die sich ihm dadurch eröffnen.
Aber nicht nur eine strukturelle Arbeitsweise kann ermöglicht werden, auch das unentdeckte Weiterleiten von Kommandos, nämlich als Gateway Funktion, kann hier eingesetzt werden. Diese abgesetzten Befehle können dann, auf Layer 2 des OSI Schichtenmodells basierend, innerhalb eines lokalen Netzes weiter verbreitet werden, insbesondere mit Hilfe der ARP und DHCP Protokolle. Auch eine maskierte und prinzipiell sehr gute Tarnung gewährende Übermittlung außerhalb von IP, nämlich über das 802.11 Protokoll, ist möglich.
Das untere Abbild zeigt eine signierte über XML stattfindende Kommunikation:

Nutzdaten
Die in “Verschlüsselung & Digitalen Signaturen” abgebildete XML Beispielkonfiguration zeigt nach dem Attribut “feature”, die in dieser momentanen Konfiguration eingesetzten Features. Die Modul- und Funktionserweiterung findet hierbei auf dem selben Weg wie ein Update der Signierung statt. Um eine neue Funktion hinzuzufügen muss der aktuelle Betreiber keine weiteren Kenntnisse über Aufbau oder Syntax des Konfigurationsscripts kennen. Lediglich das Ausführen eines Befehls wie dieses ist nötig, um die Funktion des Bots zu erweitern:
<command>
id=”module XY”>
paramter
</feature>
</command>
Die Funktionen gehen über DDos über Flooding-Attacken bis hin zu Portscan oder Keylogger. Hier sehen Sie eine Liste der Funktionen, die in unserem Beispiel verwendet werden:

  • ICMP Flood
  • SYN Flood
  • UDP Flood
  • HTTP Flood
  • SOCKS4 Flood
  • HTTP Flood
  • HTTPS Flood
  • TCP Port Umleitung
  • Software Lizenz Schlüssel Diebstahl
  • Netzwerküberwachung um Passwörter zu klauen
  • Cookies abgreifen
  • Versand von SPAM
  • Portscan
  • Keylogger

Infektionsebene
Die Alterung und Verweisung der Bots veranlasst die Botnet Betreiber immer neue Versionen entstehen zu lassen. Diese Bots sind dann zwangsweise mit neuen Funktionen und Exploits ausgestattet und werden über neue und alte Kanäle verbreitet. Der Aufwand, um eine ähnliche Verbreitung und Infektionsrate und somit Erfolgsquote zu erreichen, dürfte für die Programmierer und Entwickler solcher Bots für einige Zeit beschäftigen.
Kommuikationsebene
Nahezu alle Bots besitzen die selbe Eigenschaft, um ihr Funktionsspektrum voll auszunutzen. Sie müssen immer wissen, welche Adresse Sie für die Befehle kontaktieren müssen bzw. woher die Kommandos kommen. Dies kann in Form von Konfigurationsdateien geschehen, als auch dynamisch zur Laufzeit per HTTP oder andere Protokolle. Da diese Bots gezwungen sind zu wissen, wohin sie sich verbinden müssen, können sie auch relativ leicht abgeschaltet werden. Hierzu benötigt man lediglich die Zieladresse, um diese dann zu blockieren oder auf eine Backlist in der Firewall zu setzen. IT-Spezialisten können mit Analysemechanismen leicht die Adresse heraus finden und den Bot, und im besten Falle das ganze Botnet vom Netz nehmen.
Was ändert sich in der Botstruktur, wenn ein Bot diese Information nicht mehr benötigt?
Um dieses Mechanismus umzusetzen, wird der OTP Algorithmus (One-Time-Password; Deutsch: Einmalpasswort) benutzt. Dieses einmalig gültige Passwort wird im Internet über verschiedene Wege gestreut und zur Authentifizierung des Masters an den infizierten Rechner genutzt. Hierzu wird eine neue Timestamp je begonnener Stunde gesetzt, um ein Lauschen oder Ausspähen des Schlüssels unmöglich zu machen. Der Bot  sucht nach diesen Schlüsseln und verbindet sich dann mit dem Master, sobald ein Schlüssel passt.
Hier eine solche Umsetzung:

Um die Kommunikationspartner in Klartext sehen zu können, muss der MD5 Hash entschlüsselt werden. Damit der String keine besondere Auffälligkeit besitzt, wird der Name so gewählt, dass Länge und Charset normal “wirken”. Dieser Name wird dann z.B. über den Skype Dienst in die Userliste eingetragen und es wird kontakt zu diesem Computer aufgenommen. Über diesen Kontakt lassen sich dann weitere Kommandos empfangen.
Über das Kommunikationsmodul nimmt der Bot in unserem Beispiel Kontakt zu seinem Master auf:

Wie zuvor erwähnt generiert der OTP String in der Kontrollebene jede Stunde einen neuen String. Bei jeder neuen Generierung wird die SearchforMaster() Methode aufgerufen und ein neuer Suchvorgang nach dem exakten Dateinamen wird begonnen. Kurz nach Generierprozess wird der Seed dann in einem Gnutella Netz gestreut und bereitgestellt. Der Bot sucht dann nach dem passenden Gegenstück, und bei Übereinstimmung wird die textbasierte Datei heruntergeladen, und nach Vorgaben ausgewertet. Die Datei kann die URL als Adresse oder den Namen des Servers über DNS enthalten. Natürlich können auch nur Kommandos enthalten sein. Hier wird dann die GetNextCommand() Methode aufgerufen und ein neues behandelndes Objekt erstellt.
Quelle: www.blackhat.com