Traditionell verwenden Banking-Trojaner Konfigurationsdateien, die auf dem angegriffenen Rechner abgelegt werden. Diese Konfigurationen enthalten zum einen die Adressen der angegriffenen Internetseiten, zum anderen auch den Code, der vom Banking-Trojaner auf diese Webseiten eingefügt werden soll, genannt Webinject. Dieser Code ist dann z.B. für den Diebstahl von Zugangsdaten und persönlichen Informationen zuständig ist.
Diese Technik bringt für die Cyberkriminellen allerdings zwei entscheidende Nachteile mit sich: Es ist für Analysten relativ einfach möglich, die Konfigurationen aus der abgelegten Datei zu extrahieren und herauszufinden, welche Internetseite auf welche Art und Weise angegriffen wird. Es ist bekannt, dass Analysten eben dies tun um Angriffe zu studieren und die zuständigen Stellen zu informieren, so dass letztendlich auch die Betreiber der angegriffenen Internetseiten Gegenmaßnahmen ergreifen können.
Der zweite Nachteil besteht darin, dass die Angriffsziele für die Webinjects im Voraus bekannt sein müssen. Das bedeutet, dass der Angreifer alle Webseiten von denen er Informationen stehlen möchte in der Konfiguration seines Information Stealers auflisten muss und auch die Webinjects, also den injizierten Code, für die jeweiligen Webseiten in der Konfiguration mitliefern muss.
Ein Update der Webinjects oder auch eine Änderung der angegriffenen Webseiten benötigt folglich ein Update der gesamten Konfigurationsdatei.
Durch die Verwendung von Cloud-Techniken sind die Cyberkriminellen mittlerweile in der Lage, diese Nachteile auszugleichen.
Der erste Schritt: Spezielle Konfiguration von ZeuS
Ein Beispiel dafür ist eine spezielle Konfiguration des bekannten Banking-Trojaners ZeuS, die von G DATA Analysten vor einigen Tagen entdeckt wurde.
Die Konfiguration enthält dabei wie üblich eine Liste von anzugreifenden URLs und den zu injizierenden Code. Der Code ist in diesem Fall speziell und interessant, nachstehend in unverschleierter Form:
Anstatt wie üblich direkt den gesamten Schadcode einzufügen, wird hier nur ein kleiner Schadcode in Form von Javascript verwendet, der den ausschließlichen Zweck hat über die Funktion LoadInjectScript dynamisch weiteres JavaScript von einer Webseite des Angreifers nach zu laden. Im konkreten Fall war dies ein Skript mit PayPal als Angriffsziel, was aus angeblichen Sicherheitsgründen eine erneute Eingabe der Kreditkartendaten des Benutzers verlangt.
Diese Daten werden natürlich nach Eingabe umgehend an den Angreifer gesendet und haben überhaupt nichts mit einem offiziellen Vorgang von PayPal zu tun.
Die hier verwendete Technik des dynamischen Nachladens aus der Cloud bringt dabei einige Vorteile mit sich: Der Angreifer kann zum Beispiel bei einem Update des Layouts der angegriffenen Seite das eigene Layout anpassen, ohne allen infizierten Rechnern neue Konfigurationsdateien senden zu müssen. Auch auf eine Änderung des entsprechenden HTML-Codes kann so reagiert werden. Da jedes Mal beim Aufruf einer Webseite die angegriffen werden soll der eigentliche Schadcode in Form von Javascript in Echtzeit vom Server des Angreifers geladen wird, kann dieser nach Belieben den zurückgelieferten Schadcode anpassen.
Auch der Einsatz sogenannter Logikbomben wird dadurch möglich. Diese sorgen dafür, dass der Schadcode nur unter bestimmten Bedingungen heruntergeladen wird. Zum Beispiel kann nach Uhrzeit oder Standort gefiltert werden. Da die Standorte vieler Sicherheitsfirmen bekannt sind. können diese so gezielt ausgesperrt werden, um Analysen und Gegenmaßnahmen zu erschweren.
Die Perfektion des dynamischen Prinzips: Ciavax
Ein seit August aktiver Trojaner namens Ciavax hat dieses Prinzip perfektioniert. Denn hier wird auch die Liste der anzugreifenden Seiten geheim gehalten.
In jede aufgerufene Webseite wird folgender generischer JavaScript-Code injiziert:
Dieser relativ kurze Code lädt im zweiten Schritt den eigentlichen Schadcode dynamisch über eine PHP-Seite unter Kontrolle des Angreifers nach. Hierbei werden sowohl eine ID des anfragenden Benutzers, sowie die URL (document.URL) und der Referer (document.referer) übertragen.
Diese Technologie bringt sämtliche Vorteile der oben dargestellten ZeuS-Variante mit sich, geht aber sogar noch darüber hinaus. Für Analysten ist hier nicht mal mehr erkennbar, welche Seiten überhaupt angegriffen werden sollen. Zum Ermitteln der betroffenen Seiten wäre es höchstens möglich, mittels „Brute Force“ eine Liste von thematisch besonders gefährdeten URLs auszuprobieren. Allerdings bringt dies neben dem ausgesprochen hohen Aufwand noch einen weiteren Nachteil mit sich: Dem Angreifer würden die massiven Anfragen wahrscheinlich auffallen, und er könnte den entsprechenden Analysten von jeder Code-Auslieferung aussperren.
Zusätzlich sieht der Angreifer alle vom Opfer aufgerufenen Seiten in Echtzeit und kann entscheiden, wen er mit welchem weiteren Schadcode angreifen möchte.
Auch die in Echtzeit vom Angreifer gesammelten „digitalen Bewegungsprofile“ seiner Opfer können ihm bei der Entwicklung neuer Webinjects wichtige Informationen zur Verfügung stellen. So ist es möglich bisher noch nicht in Betracht gezogene Webseiten als Angriffsziele auszumachen, wenn diese von den Opfern häufig benutzt werden und damit lohnenswerte Ziele darstellen.
Als Fazit lässt sich sagen, dass diese Technologien nicht nur den Analysten das Leben in Zukunft deutlich schwerer machen werden, indem sie die Analysen der angegriffenen Webseiten einschränken. Auch das Ausspähen eventueller Ziele bevor ein tatsächlicher Angriff stattfindet zeugt von zunehmender Professionalisierung der Angreifer. Ebenso bemerkenswert ist die Möglichkeit, gezielt und in Echtzeit über Webinjects die Opfer anzugreifen.
G DATA schützt
G DATA erkennt diese und andere Trojaner mit Hilfe von CloseGap, dem Behaviour Blocker sowie BankGuard.
Für Forschungskollegen:
Die behandelten Samples haben folgende SHA256-Prüfsummen:
ZeuS 54f731c4aabf23ed637259218946a438869b93fe454d45b154515bda914fe4ac
Ciavax 14f6f19356c35834efaca6eb95d00f02de3fcb255d7555a098ed2904c265f7c2
