Spionage-Ring Sednit nutzt jetzt individualisiertes Exploit-Kit

Seit mindestens fünf Jahren treibt die Gruppe Sednit ihr Unwesen und hat insbesondere in Osteuropa immer wieder verschiedene Institutionen angegriffen. Neben vielen anderen neuartigen Schadprogrammen nutzte die Gruppe für diese zielgerichteten Angriffe vorrangig eine Malware, die wir Win32/Sednit genannt haben – auch bekannt als Sofacy.

Vor kurzer Zeit sind wir jedoch auf eigentlich seriöse Finanz-Webseiten gestoßen, die an ein individualisiertes Exploit-Kit umgeleitet wurden. Mithilfe von Informationen, die das Google Security Team bereitgestellt hat, konnten wir in unseren Nachforschungen herausfinden, dass dieses Kit von Sednit eingeführt wurde. Hierbei handelt es sich um eine neue Strategie der Gruppe, die bisher in der Regel von Spear-Phishing-Mails Gebrauch gemacht hat.

In diesem Post werden wir zunächst die kürzlich aufgetretenen Fälle von Spear-Phishing-Mails untersuchen, die einen Exploit gegen eine Schwachstelle in Microsoft Word (CVE-2014-1761) ausgenutzt haben. Daraufhin werden wir das Exploit-Kit unter die Lupe nehmen, von dem wir ausgehen, dass es sich noch in der Entwicklungs- bzw. Testphase befindet. Zum Schluss werden wir uns kurz mit der Payload auseinandersetzen.

Von Spear-Phishing-Mails…

Im April dieses Jahres wurde die Malware Win32/Sednit über die Zero-Day-Schwachstelle CVE-2014-1761 in Microsoft Word RTF Dokumenten verbreitet. Die Schwachstelle war offensichtlich ein gefundenes Fressen für viele Hacker, denn auch BlackEnergie und Miniduke – Malware-Familien, die ebenfalls für zielgerichtete Angriffe eingesetzt werden – haben sie ausgenutzt.

Nachfolgend seht ihr zwei Köder-Dokumente, die den Opfern angezeigt wurden, während die Schwachstelle auf ihrem Computer klammheimlich ausgenutzt wurde. In beiden Dokumenten wird über die vermeintlichen Ansichten der NATO bezüglich des Ukraine-Konflikts berichtet.

… zu einem individualisierten Exploit-Kit

Wir haben beobachtet, wie Webseiten, die zu einem großen Finanzinstitut in Polen gehören, zu einem Exploit-Kit umgeleitet wurden. Dieses wird über einen einfachen IFRAME geladen, der weiter hinten im HTML-Dokument hinzugefügt wurde – im Screenshot unten z.B. hXXp://defenceiq.us/2rfKZL_BGwEQ. Außerdem können wir einen ähnlichen IFRAME sehen, der die URL hXXp://cntt.akcdndata.com/gpw?file=stat.js lädt. Deren Domainname wurde am 18. September registriert. Zwar waren wir nicht in der Lage, den Inhalt dieser Webseite wiederherzustellen, aber wir vermuten, dass sie eingerichtet wurde, um Statistiken über die Anzahl der Umleitungen zu sammeln.

Bei dem Versuch, die URL hXXp://defenceiq.us direkt aufzurufen, wurden wir an defenceiq.com weitergeleitet. Hierbei handelt es sich um eine seriöse Webseite, die sich selbst als eine „maßgebliche Nachrichtenquelle für hochqualifizierte und exklusive Neuigkeiten und Analysen über globale Verteidigung und militärbezogene Themen“ bezeichnet.

Wie sich herausstellte, wurde die Domain zu 76.73.47.90 aufgelöst. Auch andere Domains wurden zu dieser IP-Adresse aufgelöst und legten das gleiche Verhalten in Bezug auf die Umleitung an den Tag. Das ist ein starker Indikator für den Sektor, den die Gruppe zurzeit angreift. Die Umleitung von einer Webseite eines polnischen Finanzinstituts zu einem militärbezogenen Domainnamen scheint allerdings nicht sonderlich optimal für einen zielgerichteten Angriff. Dies ist unter Umständen der Verflechtung von zwei parallel stattfindenden Kampagnen geschuldet.

Das Exploit-Kit, das wir als Referenz auf Sednit Sedkit genannt haben, verhält sich ähnlich wie andere, zurzeit beliebte Exploit-Kits, wie z.B. Angler oder Nuclear. Ein Beispiel für den Einsatz der Exploits ist unten dargestellt. Der Browser wird zunächst zur Landing-Page geleitet, die mithilfe von JavaScript den Browser und die installierten Plug-In-Versionen erkennt.

Interessanterweise wird der Aufruf von DetectJavaForMSIE() auskommentiert. Aktuelle Versionen von Java und Browser zeigen Warnungen an, bevor ein Applet geladen wird. Im Moment ist scheinbar nur der Internet Explorer betroffen. Bei einem Test mit Chrome und Firefox wurden wir immer an localhost umgeleitet.

Über eine POST-Anfrage sendet der Browser dann die Plug-In-Informationen zurück. Hierauf basierend leitet das Exploit-Kit den Browser dann entweder an eine andere URL um, die ein Exploit beinhaltet oder aber an http://localhost. Je Besuch probiert das Kit nur ein Exploit aus.

Wir haben drei verschiedene Exploits entdeckt, die von dem Kit genutzt werden, um den Internet Explorer (IE) anzugreifen. Diese sind nachfolgend aufgelistet, einschließlich der spezifischen IE-Versionen, die sie angreifen. Interessanterweise haben wir CVE-2014-1776 bisher in keinem weiteren der verbreiteten Kits entdeckt. Auch die anderen beiden Schwachstellen werden bisher nur in begrenztem Umfang ausgenutzt.

Anderen Aspekten des Kits mangelt es allerdings an Raffinesse. Anders als die meisten gegenwärtigen Exploit-Kits nutzt es keine JavaScript-Verschleierung. Wir haben im JavaScript-Code sogar Kommentare gefunden, die sich auf die ROP-Chain des Exploits beziehen. Deshalb gehen wir davon aus, dass sich das Kit noch in der Testphase befindet.

Abbildung 1 vom CVE-2013-3897 Exploit-Code

Abbildung 2 vom CVE-2014-1776 Exploit-Code

Nach der Dekomprimierung der Flash-Datei, die für CVE-2014-1776 genutzt wird, wird ein Pfad sichtbar. Diese Informationen wurden in unserem Archiv älterer Samples des Exploits nicht gefunden.

Nach der erfolgreichen Ausnutzung wird die Payload heruntergeladen. Ob es verschlüsselt ist, hängt vom jeweiligen Exploit ab.

Payload

Das Binärprogramm, das auf der infizierten Maschine ausgeführt wird, heißt „runrun.exe“. Dessen einziger Zweck besteht darin, ein zweites Programm auszuführen – ursprünglich verschlüsselt und komprimiert – und dessen dauerhafte Einnistung auf dem Gerät sicherzustellen. Bei diesem Programm handelt es sich um eine Windows-Bibliothek namens „splm.dll“. Laut unseren Daten wird diese Malware mindestens seit 2009 bei zielgerichteten Angriffen eingesetzt.

Grob zusammengefasst wurde diese Payload mit einem C++ Framework erstellt. Dank der Runtime Type Information (RTTI) kann ein Teil der Programm-Architektur mit dem vom Programmierer vergebenen Klassennamen rekonstruiert werden. Die Malware beinhaltet Agenten-Module, die schädliche Aktivitäten implementieren und Kanäle für die Kommunikation zwischen den Modulen und den Remote Controllern. In diesem Sample haben wir die folgenden Agenten-Module gefunden, identifiziert durch eine 16-Bit ID:

Es instanziiert auch einen externen Kommunikationskanal namens WinHttp, der drei Domainnamen entschlüsselt, die  für die Verbindung zur Command-&-Control-Infrastruktur genutzt werden: msonlinelive.com, windows-updater.com und azureon-line.com.

Zusammenfassung

In den vergangenen Jahren sind Exploit-Kits zu einer beliebten Methode geworden, um Crimeware unter die Leute zu bringen – Malware, die für eine massenweite Verbreitung vorgesehen ist, um beispielsweise Spam zu versenden, Bitcoin-Mining zu betreiben oder Zugangsdaten abzugreifen.

Bereits seit 2012 beobachten wir, dass diese Strategien für Spionage-Zwecke genutzt werden. Dabei sind sie unter den Bezeichnungen „Watering-Hole-Attacks“ oder „Strategic Web Compromises“ bekannt geworden. Einen Watering-Hole-Angriff kann man als die Umleitung der Besucher einer Webseite von einem strategisch ausgewählten Unternehmen oder einer Organisation beschreiben. In ESETs Rückblick auf Windows-Ausnutzungen im Jahr 2013 schrieb Artem Baranov: „Man kann das vergangene Jahr mit Recht als das Jahr der zielgerichteten Attacken und der Watering-Hole-Angriffe bezeichnen.“

Während die Gefahren durch Watering-Hole-Angriffe bekannt und zum Teil sogar gut dokumentiert sind (wie z.B. von Symantec im Elderwood Project Report), sind sie nach wie vor eine beliebte Strategie von cyberkriminellen Gruppen. Und es ist nicht abzusehen, ob sich das in Zukunft ändern wird.

Indikatoren für eine Beeinträchtigung des Systems

Hier findet ihr einige Indikatoren, die dabei helfen können, das Payload-Sample zu identifizieren, das – wie im Artikel beschrieben – von dem Exploit-Kit eingeführt wird.

• Vorhandensein der CLSID {d702b440-b130-47f7-a94c-c1fae33d2820} unter dem Registry Key HKLM\Software\Microsoft\Windows\CurrentVersion\ShellServiceObjectDelayLoad
• Mutex namens „XSQWERSystemCriticalSection_for_1232321“
• Mailslot namens „\\.\mailslot\check_mes_v5555“
• Dateien im temporären Ordner (wie von %GetTempPath() übergeben) namens „edg6EF885E2.tmp“ und „edg6E85F98675.tmp”
• Netzwerkkommunikation mit den Domains namens msonlinelive.com, windows-updater.com oder azureon-line.com

Hashes