Die Welt der Keylogger ist groß. Alleine diese Tatsache macht es nicht leicht einen Keylogger im System so ohne weiteres zu finden. Warum nicht? Hat der Angreifer den Keylogger durch einen Crypter geschickt, lässt sich dieser mit einem normalen Anti-Virus Programm oft nicht mehr erfassen. Zusätzlich stellt sich die Frage, wie arbeitet der Keylogger?

Es gibt Keylogger, die erst mal die erfassten Daten in eine Datei ablegen. Jetzt könnte der Suchende versuchen alle Dateien nach einem gewissen Inhalt zu durchsuchen. Findet er etwas, so stimmt etwas nicht. Jedoch sind die Programmierer recht schlau und verschlüsseln leicht oder schwer, je nach Geschmack, den erfassten Inhalt und legen diese Daten in den alternativen Datenströmen ab. Auf diese Weise fällt dem normalen Benutzer nicht auf, dass eine Datei immer größer wird und zudem noch immer offen ist. Der Suchende könnte ein Programm verwenden, welches alle offenen Dateien anzeigt, welches eine Menge sein wird. In dieser Liste sollte möglichst nichts Ungewöhnliches stehen. Also tarnen die Programmierer den Programmdateinamen etwas. Zum Beispiel: notepad.exe:29a. Nun befinden sich zwei Dateien unter dem Namen notepad.exe. Damit der Zweite wiedergefunden werden kann, trägt dieser einen Unternamen, hier 29a. Unter dem Windows Explorer wird hier nichts Verdächtiges angezeigt, da dieser die ADS nicht darstellt. Also ein ganz gutes Versteck als Zwischenpuffer für einen Keylogger.

Der obige Gesichtspunkt mal dahingestellt. Muss der Keylogger immer Daten senden? Nicht unbedingt. Wenn nicht live mit einer RAT auf das System gelinst wird, kann er das auch Etappenweise machen. Auch hier gibt es viele Ideen, die ein Programmierer umsetzen kann. Der Keylogger liest die E-Mail Kontodaten des Systems aus und versendet mit einer eigenen Routine eine Mail, wo die Daten mit versendet werden. Im Wireshark sieht man daher oft SSL und die Domain, smtp.meinprovider.de stimmt ja auch. Wenn die Zeitstempel nicht darauf hinweisen, dass gerade der Benutzer keine Mail versendet hat, nun ja – es fällt kaum auf. Andere Ideen ist das Senden der gespeicherten Daten, wenn gewisse Sachen mit dem Rechner gemacht werden. Ruft der Benutzer eine Suchmaschine auf oder sendet eine Suchanfrage, so werden dann die Daten versendet. Das Schöne an diesem Muster ist, dass der Benutzer oft nicht große Teile von Daten mitschneidet und analysiert, sondern immer nur kurze Minutenstücke. Dabei ruft er aber selten etwas bei Google ab, während er auf dem System stöbert. Damit minimiert der Programmierer die Wahrscheinlichkeit, dass die Sendung entdeckt wird. Zusätzlich könnten die Daten auch als HTTP Traffic getarnt werden. Dazu sendet der Keylogger HTTP Aufrufe an eine Domain und überträgt die Daten als normale Parameter. Man denke noch an eine triviale Verschlüsselung und an dem Domainname: updates.ativr32.com. So ohne weiteres fällt es auf dem ersten Blick auch in Wireshark nicht auf, wenn hier und da mal ein paar KB ausgetauscht werden. Auch getarnt als DNS Traffic ist es schwer einfach so zu erkennen, dass es sich um eine Datenübertragung handelt. Hierbei werden normale DNS Aufrufe geformt, die entsprechend an einen selbst gebauten DNS Server gehen, der mit den zusätzlichen Daten etwas anfangen kann.

Doch warum der ganze Zauber? Wegen der Firewall. DNS Pakete werden oft unkommentiert durchgelassen, wie auch HTTP. Auch eine Mail geht oft ohne weiteres raus. Sind die Daten erst mal weg, ist das Kind schon im Brunnen am Wassertreten. Damit die Firewalls möglichst nichts bemerkt, kann sich der Keylogger an Systemprozesse hängen oder an Prozesse wie Thunderbird oder Outlook. Mit dem Process Explorer lässt sich hier und da so etwas erkennen. Natürlich erkennen viele Internet Security Suites auch verdächtige Aktivitäten und blocken das, wenn gewünscht. Jedoch ein normales Anti-Virus Programm ist hierbei fast immer still.

Somit sei etwas dargestellt, dass das Erfassen von Datenströmen von Keyloggern unter Wireshark nicht so einfach ist. Dennoch ist es eine gute Idee ein Auge auf seiner Internetverbindung zu haben. Vielleicht ist der Einsatz eines Proxyservers eine schöne Sache. Surft der Benutzer nur, so kann einmal der Proxy ein sehr genaues Log führen und zudem alles wegwerfen, was nicht in eine HTTP Verbindung gehört. Mail und FTP und was nicht alles kann entweder durchgelassen werden oder es wird auch geblockt. Den Computer noch in ein neues Subnetz, was kein Gateway bekommt und ein zweiter Rechner, der Proxy spielt für das Subnetz mit zwei Ethernet-Karten. Fertig. Die Maschine ist damit einmal aus dem Internet sehr schwer zu erreichen, da sich NAT und PAT ohne Gateway erledigt hat. Gleichzeitig kommt nur die Dinge über den Proxy raus, die der Benutzer auch erlaubt hat. Und das Log, falls gewünscht, kann riesig werden. Je nach Detailgrad. Da findet der Benutzer alles, was passiert ist. Gut, es schützt nicht vor Drive-by-Downloads und so weiter, aber dennoch würde eine RAT nicht über den Proxy nach außen kommen. Für die Malware gibt ja ein AV Programm.

Urlsnarf ist ein kleines Programm, welches in dem dsniff Paket mitgeliefert wird. Bei dem Programm handelt es sich um einen HTTP Sniffer, der seine Ausgaben im Common Log Format ausgibt. Damit lassen sich die Daten gleich in Web Log Analyser aufbereiten. Damit erhält ein Schnüffler schnell eine Übersicht, wo die Leute im Netzwerk so herumsurfen. Als Web Log Analyser kann beispielsweise SawMill, wwwstat oder ana-log verwendet werden.

urlsnarf kann mit einigen Optionen gefüttert werden. -n weist urlsnarf an, keine IP Adressen über DNS aufzulösen. -i definiert das Netzwerkinterface mit dem gearbeitet werden soll. Desweiteren können mit regulären Ausdrücken URLs definiert werden, worauf urlsnarf achten soll, falls der Schnüffler einen gewissen Kreis von Seiten im Fokus hat.

urlsnarf ist auf der Backtrack, wie auch auf der GRML Live CD zu finden. Dazu läßt es sich natürlich auch unter Ubuntu nachinstallieren. Paketname: dsniff.

urlsnarf kann recht gut zusammen mit ettercap verwendet werden. Schließlich müssen die Daten ja auch am Interface vorbeilaufen, um sie Sichten zu können.

Weiterführende Ideen könnten sein, noch ein transparanten Proxy in die Kette mit einbauen, der entsprechend auf einer ganz bestimmten Seite das LoginScript so umändert, dass die Kennwörter, die sonst per SSL übertragen werden, auch zum Angreifer hinwandern, schon kommt man ohne die SSL Kette beschädigen zu müssen an Logins, ohne dass das grüne Häckchen rot wird.

Das Programm macof ist ein Flodder. Das Programm befindet sich auf der GRML und auf der Backtrack Live CD. Unter Ubuntu läßt es sich schnell mit apt-get nachinstallieren. Macof flutet ein geswitchtes LAN mit Paketen, die zufällige MAC-Adressen beinhalten. Doch warum wird so etwas gemacht? Das Fluten mit Paketen dieser Art dient keinem DOS Angriff. Vielmehr möchte der Angreifer erreichen, dass die MAC-Tabelle auf dem Switch volläuft. Damit wird erreicht, dass ein Switch sofort als ein Multiport-Repeater arbeitet und alle Pakete, wie ein gewöhnliches Hub, zu allen Rechner weiterleitet. Im Standard steht dieses Verhalten festgeschrieben, jedoch regieren nicht alle Geräte gleich. Besonders, wenn das Switch Sicherheitsfunktionen besitzt, wie alle professionellen Cisco Switches, wird dem Angreifer schnell ein Shutdown des Ports beschert. Es gibt auch IDS Systeme, die einen Flood erkennen und entsprechend Alarm schlagen.

Gut, der Angreifer hat erfolgreich das Switch geflutet und kann nun für eine gewisse Zeit den ganzen Traffic im LAN lesen. Mit Wireshark geht das für gewöhnlich im ganz gut. Stoppt das Fluten, so wird das Switch nach einer gewissen Zeit seine Tabelle aufräumen und schon ist der Zauber wieder vorbei. Somit muss der Angreifer über den ganzen Zeitraum seine Aktivitäten das Switch damit fluten. Ist das Gateway des Subnetzes bekannt und soll entsprechend der dort auslaufende Traffic abgehört werden, ist es sinnvoll das Gateway zu spoofen, um die Pakete dann durch seinen eigenen Rechner umzuleiten und anschließend zum echten Gateway.

Mit dem macof Parameter -i bestimmt der Angreifer das Netzwerk-Interface, woraus die gespooften Mac-Frame herauswandern sollen. Mit -s übergibt der die Quell-IP-Adresse, die das Paket beinhalten soll. Mit -d nun die Ziel IP Adresse. Diese kann existieren, muss aber nicht. Genauso, wie die Quell-IP. Mit -e wird die Mac-Adresse bestimmt. -x gibt das TCP Sourceport an und -y das TCP Destinationport. Das Wichtigste ist -n, welches die Anzahl der zu sendenden Pakete bestimmt.

Projekt: Neurodump is proudly powered by WordPress and the Theme Adventure by Eric Schwarz
Entries (RSS) and Comments (RSS).

Projekt: Neurodump

Gedankenauszüge eines Datenreisenden