Alle Bedrohungen

Viren

Hacker

Spam

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

 
Kalender

<< 2015  
Jan Feb Mär
Apr    
     
     
Ü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

Simdas Versteckspiel: kein Kinderkram


  Vitaly Kamluk       13 April 2015 | 19:27  MSK

Ihr Kommentar  

Am 9. April waren Kaspersky Lab und INTERPOL an der synchronisierten Operation zur Zerschlagung des Simda-Botnets beteiligt, die vom INTERPOL Global Complex for Innovation koordiniert wurde. In diesem Fall wurden die Ermittlungen zunächst von Microsoft eingeleitet und dann ausgeweitet, so dass sich der Kreis der Beteiligten unter anderem auf die folgenden Organisationen erstreckte: TrendMicro, das Cyber Defense Institute, die niederländische NHTCU, das FBI, die Police Grand-Ducale Section Nouvelles Technologies in Luxemburg und das für Cyberkriminalität zuständige Department "K" des russischen Innenministeriums, unterhalten vom nationalen Zentralbüro von INTERPOL in Moskau.

Im Rahmen der Zerschlagungs-Aktion wurden 14 C&C-Server konfisziert, die sich in den Niederlanden, den USA, Luxemburg, Polen und Russland befanden. Eine vorläufige Analyse einiger der abgefangenen Server-Logs förderte eine Liste von 190 Ländern zutage, die von der Aktivität des Simda-Botnets betroffen sind.


Simba, die liebenswerte Walt Disney-Figur, hat nichts mit dem Simda-Botnet zu tun

Simda ist ein mysteriöses Botnet, das zu kriminellen Zwecken benutzt wird, z.B. zur Verbreitung potentiell unerwünschter und schädlicher Software. Dieser Bot ist deshalb mysteriös, weil er nur selten auf unserem KSN-Radar erscheint, obwohl er täglich eine große Zahl von Hosts kompromittiert. Das liegt teilweise an der Erkennung von Emulation, Sicherheitstools und virtuellen Maschinen. Die Schadsoftware verfügt über eine Reihe von Methoden, Sandbox-Umgebungen zu erkennen, in der Absicht die Malware-Analysten auszutricksen, indem die gesamten CPU-Ressourcen aufgezehrt werden oder der Botnet-Betreiber über die IP-Adresse des Analysten-Netzwerks informiert wird. Ein weiterer Grund ist ein serverseitiger Polymorphismus und die eingeschränkte Lebensdauer der Bots.

Simda wird von einer Reihe infizierter Websites verbreitet, die auf Exploit-Kits umleiten. Der Bot verwendet hart codierte IP-Adressen, um seinen Meister über verschiedene Stadien des Ausführungsprozesses in Kenntnis zu setzen. Er lädt zusätzliche Komponenten von seinen eigenen Update-Servern und führt sie aus, zudem ist er in der Lage, die Systemdatei hosts zu modifizieren. Letztgenanntes ist eine recht interessante Technik, auch wenn sie auf den ersten Blick zu offensichtlich erscheint.

Normalerweise modifizieren Malware-Autoren die host-Dateien, um Suchmaschinenergebnisse zu manipulieren oder einige Sicherheitssoftware-Websites auf die Schwarze Liste zu setzen, doch der Simda-Bot fügt unerwartete Einträge für google-analytics.com und connect.facebook.net hinzu, um auf schädliche IPs zu verweisen.

Wozu das, mag man sich fragen? Wir wissen es nicht, doch wir glauben, dass die Antwort mit Simdas eigentlicher Bestimmung zusammenhängt - der Verbreitung anderer Malware. Das kriminelle Geschäftsmodell eröffnet die Möglichkeit exklusiver Malware-Verbreitung. Das bedeutet, die Verbreiter können dafür garantieren, dass nur die Malware des Kunden auf den infizierten Rechnern installiert wird. Und das ist der Fall, wenn Simda eine Antwort von dem C&C-Server interpretiert – er kann sich selbst deaktivieren, indem er den Bot davon abhält, beim nächsten Reboot zu starten und umgehend aussteigt. Diese Deaktivierung geht mit der Modifizierung der hosts-Systemdatei einher. Als Abschiedsgeste ersetzt Simda die originale hosts-Datei durch eine neue aus seinem eigenen Körper.

Der neugierige Leser mag nun fragen: Was nützt ihm das alles? Diese Domains werden nicht länger benutzt, um Suchergebnisse zu generieren, sondern mit Simda infizierte Rechner haben in der Vergangenheit gelegentlich weiter http-Anfragen an schädliche Server geschickt, selbst wenn vermutet wird, dass ausschließlich Malware von dritter Seite installiert ist.

Wir dürfen nicht vergessen, dass diese Rechner ursprünglich von einem Exploit-Kit infiziert wurden, das eine Sicherheitslücke in nicht gepatchter Software ausnutzt. Es ist höchstwahrscheinlich, dass Fremd-Malware mit der Zeit entfernt wird, aber ein sorgloser Nutzer kommt vielleicht nie auf die Idee, angreifbare Software zu aktualisieren.

Wenn alle diese Hosts zu den schädlichen Servern zurückkehren und Webressourcen wie etwa Javascript-Dateien anfragen, könnten Kriminelle dieselben Exploits nutzen, um die Computer erneut zu infizieren und sie noch einmal von vorn zu verkaufen – vielleicht sogar „exklusiv“ an den ursprünglichen Kunden. Womit einmal mehr bewiesen wäre – selbst Verbrecher können Verbrechern nicht trauen.

Bei diesen Ermittlungen schlossen Microsoft und verschiedene Strafverfolgungsbehörden den Sinkholing-Prozess ab und Kaspersky Lab leistete gern einen Beitrag zur Vorbereitung der Botnet-Abschaltung. Dazu gehörte die technische Analyse der Malware, das Sammeln von statistischen Infektionsdaten, Empfehlungen zur Beschlagnahmungsstrategie sowie Beratungen mit unseren Partnern von INTERPOL.

Kaspersky Lab detektiert den Simda-Bot als Backdoor.Win32.Simda und unseren Schätzungen zufolge, die auf den KSN-Statistiken und den Daten unserer Partner basieren, sind weltweit hunderttausende Opfer betroffen.

Simda wird automatisch bei Bedarf generiert, wovon auch das völlige Fehlen jeglicher Regelmäßigkeit bei den Linkzeiten zeugt. Unten stehend eine Grafik, die von einer kleinen Untermenge von etwa 70 zufälligen Simda-Samples erstellt wurde:


Linkzeiten der Samples in der UTC-Zeitzone

Die Zunahme der Linkzeiten hat aller Wahrscheinlichkeit nach mit der Aktivität der meisten Simda-Opfer zu tun, die sich irgendwo in den Zeitzonen zwischen UTC-9 und UTC-5 befinden, was die USA einschließt.

Dank der Sinkhole-Operation und den unter den Partnern ausgetauschten Daten konnten wir eine Seite erstellen, auf der Sie überprüfen können, ob Ihre IP in der Vergangenheit mit den C&C-Servern von Simda verbunden war. Wenn Sie den Verdacht haben, dass Ihr Computer kompromittiert wurde, nutzen Sie unsere kostenlose Lösung oder unsere Testversion, um Ihre gesamte Festplatte zu scannen, oder installieren Sie Kaspersky Internet Security als langfristigen Schutz.

Die Produkte von Kaspersky Lab detektieren aktuell hunderttausende von Simda-Modifikationen, zusammen mit vielen unterschiedlichen Fremd-Schadprogrammen, die im Rahmen der Simda-Kampagne verbreitet werden.

References:

Darwin Nuke


  Anton Ivanov       10 April 2015 | 14:00  MSK

Ihr Kommentar  

Andrey Khudyakov, Maxim Zhuravlev, Andrey Rubin

Im Dezember 2014 entdeckten wir eine sehr interessante Sicherheitslücke im Darwin-Kernel – ein wichtiger Open-Source-Bestandteil der zwei Betriebssysteme von Apple: OS X und iOS. Das bedeutet, dass auch OS X 10.10 und iOS 8 angreifbar sind. Diese Sicherheitslücke hat mit der Verarbeitung eines IP-Pakets zu tun, das eine bestimmte Größe und ungültige IP-Optionen hat. Die Folge ist, dass entfernte Angreifer eine Dienstblockade, DoS, auf einem Gerät hervorrufen können, auf dem OS X 10.10 oder iOS 8 installiert ist. Angreifer müssen dem Opfer also nur ein inkorrektes Netzwerkpaket schicken, um dessen System abstürzen zu lassen.


OS X 10.10 Absturz nach der Verarbeitung eines ungültigen Netzwerkpakets

Während der Analyse dieser Sicherheitslücke entdeckten wir, dass die Geräte mit 64-Bit-Prozessoren sowie die folgenden iOS 8-Geräte von dieser Bedrohung betroffen sind:


  • iPhone 5s und spätere Modelle
  • iPad Air und spätere Modelle
  • iPad mini 2 und spätere Modelle

Um die Natur dieses Bugs zu verstehen, werfen wir einmal einen Blick auf den Speicherauszug zum Zeitpunkt des Absturzes:


Kernel-Stacktrace

Man sieht auf diesem Auszug, dass in der Funktion icmp_error() etwas falsch gelaufen ist. Sie ruft die panic function auf. Diese Funktion versucht, eine neue ICMP-Fehlermeldung zu konstruieren und sie erneut zu senden. Der Screenshot zeigt, dass der icmp_error nach dem Parsen der Paketoptionen aufgerufen wurde. Das Problem liegt in diesem Teil des Codes:


Die Ursache des Problems

Wenn die im Code festgelegten Bedingungen erfüllt werden, wird die panic function aktiviert und das System wird in den Notbetrieb heruntergefahren. Das passiert, weil die internen Kernelstrukturen geändert wurden und die neue Puffergröße zu gering ist, um ein neu generiertes ICM-Paket zu speichern. Um das zu erreichen, müssen die folgenden Kriterien erfüllt werden:


  • Die Größe des IP-Headers sollte 60 Bytes betragen.
  • Die Größe der IP-Payload sollte mindestens 65 Bytes betragen.
  • Es sollte Fehler in den IP-Optionen geben (ungültige Größe einer Option, Klasse etc.)


Beispiel für ein Paket, das einen Absturz verursacht

Auf den ersten Blick wird nicht klar, wie dieser Bug effektiv ausgenutzt werden kann. Doch ein echter Profi kann mit Hilfe dieser Sicherheitslücke problemlos ein Anwendergerät außer Gefecht setzen oder sogar die Arbeit eines Unternehmensnetzwerks zum Erliegen bringen.

Normalerweise wird diese Art von inkorrekten Paketen von Routern und Firewalls ausgelassen, doch wir entdeckten verschiedene Kombinationen von inkorrekten IP-Optionen, die die Internet-Router durchlaufen können.

Diese Sicherheitslücke ist in OS X 10.10.3 und iOS 8.3 nicht mehr vorhanden. Nutzer von Kaspersky Lab-Produkten sind zudem auch in der Version OS X 10.10 durch das Feature Network Attack Blocker vor dieser Sicherheitslücke geschützt. Beginnend mit Kaspersky Internet Security für Mac 15.0, wird diese Bedrohung als DoS.OSX.Yosemite.ICMP.Error.exploit detektiert.

Wie ich mein Fitness-Armband hackte


  Roman Unuchek       26 Mrz 2015 | 14:00  MSK

Ihr Kommentar  

Die Geschichte, die ich hier erzählen möchte, begann vor einigen Monaten, als ich ein Fitness-Armband einer populären Marke in die Finger bekam. Da es sich dabei um ein so genanntes „Wearable“ handelt, habe ich mir die App (speziell für Wearables) Android Wear installiert. Diese App verband sich ohne Probleme mit dem Fitness-Armband.

Eine Sache war allerdings merkwürdig: Das Programm verband sich mit einem „Nike+ Fuel Band SE”, aber ich hatte ein Armband eines anderen Herstellers. Recht schnell fand ich heraus, dass das Nike-Armband meinem Kollegen gehört. Und er hatte noch nicht einmal bemerkt, dass ich mich mit seinem Gerät verbunden hatte.

So entstand die Idee für eine kleine Untersuchung, um die Sicherheit meines Armbands zu prüfen.

Smarte Armbänder: Kommunikation mit dem Telefon

Derzeit werden viele Fitness-Armbänder angeboten, die zwar von unterschiedlichen Herstellern stammen, untereinander aber sehr ähnlich sind. Die unten stehende Grafik zeigt eine Statistik des Kaspersky Security Network (KSN) zur Installation von Android-Apps, die für die Zusammenarbeit mit populären Fitness-Trackern auf den mobilen Geräten der Nutzer vorgesehen sind (die Informationen für die Statistik haben wir von KSN-Anwendern erhalten, die der Datenübermittlung zugestimmt haben).


Verteilung der Installationen von Android-Apps für Fitness-Tracker verschiedener Hersteller

Obwohl es sich um eine Statistik zur Häufigkeit von Android-Apps handelt (wir haben keine Garantie dafür, dass die Anwender tatsächlich auch die entsprechenden Geräte besitzen), so spiegelt sie doch bis zu einem gewissen Grad auch die Popularität tragbarer Geräte wider.

Für die Kommunikation mit dem Smartphone nutzen die meisten Fitness-Armbänder die Technologie Bluetooth LE (auch bekannt als Bluetooth Smart). Das heißt, die Geräte verbinden sich nicht auf die gleiche Weise wie über das ‚traditionelle‘ Bluetooth. Es gibt kein allgemeines Passwort, denn die meisten Armbänder haben keinen Bildschirm oder keine Tastatur.

Armbänder mit Bluetooth-LE-Unterstützung verwenden das Generic Attribute Profil, abgekürzt GATT. Das bedeutet, dass es auf dem tragbaren Gerät eine gewisse Auswahl an Services gibt, von denen jeder über unterschiedliche Eigenschaften verfügt. Jede Eigenschaft enthält einen Bytepuffer und eine Liste von Deskriptoren, jeder Deskriptor enthält einen Wert – den Bytepuffer.

Um das zu verdeutlichen, habe ich mir einen fertigen Code aus dem Google-Software-Kit Android SDK genommen – ein Beispiel für eine App zum Verbinden mit Bluetooth-LE-Geräten. Ich musste nicht eine einzige Codezeile schreiben, sondern habe einfach ein bereits bestehendes Projekt im Android Studio geöffnet und den Start-Button gedrückt.

Auf dem Screenshot oben ist das Resultat der Verbindung mit meinem Fitness-Armband mit Hilfe dieser App zu sehen. Dort sind die Services und ihre Eigenschaften dargestellt. Doch für mein Armband ist es nicht so einfach, Daten aus diesen Eigenschaften zu erhalten. Zu diesem Zweck muss es nicht nur verbunden, sondern auch authentifiziert sein. Bei einigen anderen Geräten gelang es mir, Daten aus den Eigenschaften und ihren Deskriptoren zu lesen. Es ist durchaus möglich, dass es sich dabei um Anwenderdaten handelt.

Scan

Mir ist es also unter Verwendung eines App-Beispiels aus dem Android SDK gelungen, mich mit mehreren Geräten zu verbinden. Daraufhin erstellte ich meine eigene App, die automatisch nach Bluetooth-LE-Geräten sucht, und versuchte, mich mit ihnen zu verbinden und an ihre Service-Listen zu kommen.

Unter Einsatz dieser App führte ich mehrere Scans durch.


  • Innerhalb von zwei Stunden konnte ich mich in der Moskauer U-Bahn mit 19 Geräten verbinden: mit elf FitBit-Armbändern und acht Jawbone-Armbändern.

  • Im Laufe einer Stunde wurden in einem Fitnessclub in der Stadt Bellevue im US-Bundesstaat Washington 25 Geräte erkannt: 20 Fitbit-Armbänder und je ein Gerät von Nike, Jawbone, Microsoft, Polar und Quans.

  • Innerhalb von zwei Stunden konnte ich mich während der IT-Sicherheitskonferenz SAS2015 in Cancún mit zehn Fitness-Trackern verbinden, und zwar mit drei Jawbone- und sieben FitBit-Geräten.


Ich musste insgesamt nur sechs Stunden scannen, um mich mit 54 Geräten verbinden zu können. Und das, obwohl mir dabei zwei ernsthafte Einschränkungen im Weg standen:


  1. Auch wenn in den Handbüchern eine Distanz von 50 Metern angegeben ist, so ist die reale Distanz, innerhalb derer eine Verbindung zwischen Smartphone und Fitness-Armband möglich ist, in den meisten Fällen nicht größer als sechs Meter.

  2. Mit einem bereits verbundenen Gerät sollte man sich nicht verbinden können. Ist Ihr Gerät mit Ihrem Telefon verbunden, sollte es also selbst beim Scannen nicht für andere sichtbar sein.

Die zweite Einschränkung bedeutet im Prinzip, dass das Gerät nicht angegriffen werden kann, solange es mit einem Smartphone verbunden ist. In Wirklichkeit stimmt das aber nicht. Hier ein Beispiel: Mit Hilfe meiner Scan-App konnte ich die Kommunikation zwischen meinem Fitness-Tracker und der offiziellen Anwendung blockieren, obwohl diese vorher verbunden waren.

Berücksichtigt man den zweiten Punkt der oben aufgeführten Einschränkungen, so kann man annehmen, dass die von mir entdeckten Geräte noch nie mit einem Telefon verbunden waren, oder dass das Armband während des Scans nicht mit einem Smartphone verbunden war (Bluetooth war auf dem Telefon deaktiviert). Oder ein bereits verbundenes Gerät war für eine Verbindung verfügbar, ungeachtet der vermuteten Einschränkung. Wie dem auch sei – die Chancen, sich mit einem Fitness-Tracker zu verbinden, sind für Cyberverbrecher durchaus groß.

Um Zugriff auf die Anwenderdaten zu erhalten, reicht es in den meisten Fällen allerdings nicht aus, mit dem Gerät verbunden zu sein, sondern man muss sich auch authentifizieren. Schauen wir uns einmal an, wie die Authentifizierung bei meinem Armband abläuft.

Mein Armband: Authentifizierung

Um das Armband auf dem Telefon zu authentifizieren, verwendet die offizielle Anwendung eine von vier Services auf dem Armband. Für jede Eigenschaft aus diesem Service installiert die App das Flag „CharacteristicNotification“. Auf diese Weise teilt die App dem Armband mit, dass sie über jede beliebige Änderung dieser Eigenschaft benachrichtigt werden will. Daraufhin erhält die Anwendung die Liste der Deskriptoren für jede Eigenschaft und installiert das Flag „ENABLE_NOTIFICATION_VALUE“ – so teilt die Anwendung dem Armband mit, dass sie über jede beliebige Änderung jedes Deskriptors benachrichtigt werden will.

Danach ändert eine der Eigenschaften ihren Wert, nämlich den Bytepuffer. Die App liest diesen Puffer aus dem Armband aus: Header 200f1f und Byte-Array – nennen wir den Bytepuffer authBytes.

Die Anwendung erstellt ein neues Array. Sein erster Teil ist ein konstantes Array, das in der Anwendung enthalten ist und mit 6dc351fd44 beginnt. Der zweite Teil des neuen Arrays ist authBytes. Die App erhält die MD5-Hashfunktion von dem neuen Array und sendet sie in der folgenden Struktur an das Gerät:


  • Header (201210051f)

  • Md5

  • Kontroll-Byte


Daraufhin sendet die Anwendung ein weiteres Array an das Gerät, das ebenfalls in dieser App enthalten ist.

Danach fängt das Armband an zu vibrieren. Der Anwender muss nun lediglich einen Knopf drücken und die Authentifizierung ist abgeschlossen.

Bei der offiziellen App dauert der Authentifizierungsprozess etwa 15 Sekunden. Ich habe eine App erstellt, die nur vier Sekunden braucht, um das Armband zum vibrieren zu bringen.

Es ist leicht, den Nutzer dazu zu bringen, einen einzelnen Knopf zu drücken. Man muss nur hartnäckig sein: Der Authentifizierungsprozess lässt sich viele Male neu starten, solange der Anwender trotz allem nicht den Knopf drückt, oder solange er sich nicht weiter als sechs Meter von dem Gerät entfernt.

Ist die Authentifizierung abgeschlossen, können die Daten auf meinem Armband nach Lust und Laune ausspioniert werden. Zum gegenwärtigen Zeitpunkt befinden sich nicht allzu viele Informationen auf tragbaren Fitness-Trackern. In der Regel sind das die Zahl der Schritte, die Schlafphasen und der Puls innerhalb der letzten Stunde. Ungefähr einmal pro Stunde übermittelt die Anwendung alle Informationen vom Armband in die Cloud.

Nach der Authentifizierung lassen sich auf dem Gerät problemlos Befehle ausführen. Um beispielsweise die Zeit umzustellen, benötigt man ein Byte-Array, das mit f0020c beginnt, und dann das Datum in folgender Form: YYYY MM DD DW HH MM SS MSMSMSMS.

Bei anderen Fitness-Trackern ist alles noch viel einfacher: Bei einigen von ihnen ist ein Teil der Daten sofort nach der Verbindung verfügbar, und der Code der App für Geräte von Nike ist noch nicht einmal in irgendeiner Art und Weise verschlüsselt und lässt sich daher sehr leicht lesen (die Ergebnisse einer Untersuchung finden Sie hier).

Fazit

Wie die Ergebnisse meiner kleinen Studie gezeigt haben, kann man sich in einigen Fällen mit einem tragbaren Gerät verbinden, ohne dass der Nutzer davon weiß.

Würden Cyberkriminelle mein Armband hacken, so könnten sie nicht auf alle Daten zugreifen, denn sie werden nicht auf dem Armband oder auf dem Telefon gespeichert, da die offizielle App alle Informationen regelmäßig vom Armband in die Cloud hochlädt.

Fitness-Tracker werden immer beliebter und erhalten immer mehr Funktionen. Es ist durchaus denkbar, dass sie schon bald wesentlich mehr Sensoren und auch wesentlich mehr Anwenderinformationen enthalten werden, unter anderem medizinische Daten. Und trotzdem drängt sich der Eindruck auf, dass die Hersteller dieser Geräte sich über das Thema Sicherheit nicht allzu viele Gedanken machen.

Stellen Sie sich einmal folgendes vor: Wenn ein mit Pulsmesser ausgestattetes Armband gehackt wurde, kann der Inhaber eines Ladens die Pulsfrequenz eines Käufers verfolgen, während dieser die Angebote in seinem Shop betrachtet. Auf dieselbe Weise lässt sich auch die Reaktion potenzieller Kunden auf Werbung nachvollziehen. Ein gehacktes Pulsmesser-Armband lässt sich sogar als Lügendetektor einsetzen.

Selbstverständlich sind auch weitaus schädlichere Aktivitäten denkbar, wie beispielsweise der Einsatz eines Schadprogramms des Typs Trojan-Ransom, also eines Erpresserprogramms. Ein Verbrecher könnte sich die Kontrolle über Ihr Armband verschaffen und es dazu bringen, ununterbrochen zu vibrieren. Für die Deaktivierung der Vibration könnte er dann Geld verlangen.

Wir haben unsere Erkenntnisse dem Hersteller meines Armbands übermittelt. Das Unternehmen stufte unsere Untersuchungsergebnisse daraufhin als einen UX-Bug und nicht als Sicherheitsproblem ein. Aus ethischen und sicherheitsrelevanten Gründen werden wir Name und Modell des Armbands zum jetzigen Zeitpunkt nicht nennen. Sollten Sie sich Sorgen über mögliche Folgen einer Ausnutzung dieses Sicherheitsproblems in freier Wildbahn machen, so scheuen Sie sich nicht, den Hersteller zu kontaktieren und ihn zu fragen, ob das Produkt, das Sie benutzen, von der in diesem Artikel beschriebenen Methode betroffen ist.

Wir hoffen außerdem, dass dieser Bericht nicht nur für Anwender, sondern auch für die Hersteller der Armbänder hilfreich ist, um ihre Geräte hinsichtlich der IT-Sicherheit weiter zu verbessern.

Date mit Lisa - für nur einen Euro


  Marco Preuss       12 Mrz 2015 | 13:03  MSK

Ihr Kommentar  

Neulich Abend erhielt ich eine unerwartete SMS auf eins meiner Telefone. Eine Nachricht von "Lisa", die vorgab, mich zu kennen, inklusive einer URL, die den Leser der Mitteilung auf ein Foto von ihr locken sollte.

Die Kurz-URL verweist auf die Domain "m.bensbumsblog.com", die schon dafür bekannt ist, in SMS-Spam für Dating-Websites benutzt zu werden, indem sie den Nutzer auf eine solche Site umleitet. Da es keine vorhergehende Registrierung und auch kein Abonnement gab, gehört das hier zweifellos in die Kategorie unerwünschte Massenversendungen.

Das endgültige Ziel des Links ist "daily-date.de". Diese Website macht eine Registrierung erforderlich (Benutzername, Passwort, E-Mail-Adresse und einige persönliche Fragen). Schließlich wird dem Anwender Premium-Zugriff auf das System angeboten, was eine Suchfunktion, Treffen und Simsen mit anderen Personen sowie das Anschauen von Bildern beinhaltet, allerdings nicht kostenlos. Beworben wird hier ein 14-tägiges Probeabo zum Preis von 1€.

Die Domain "bensbumsblog.com" wird von einem Anonymisierungsdienst geschützt, um die Identifizierung des Besitzers zu verhindern. Wobei die IP-Adresse einem Cloud-Service gehört (laut RIPE-Datenbank) und von einer Marketing-Firma gepachtet wird (IP Reverse-Lookup).

Die Endgültige Website "daily-date.de" gehört einem deutschen Unternehmen in Berlin.

Ein Blick auf die Klick-Statistiken von "bit.ly" zeigt, dass diese Kampagne am 03.03.2015 startete und es innerhalb von 18 Stunden auf mehr als 10.000 Klicks brachte, wobei die meisten aus Deutschland stammten. Die meisten Klicks erfolgten in den ersten 3 Stunden dieser Kampagne (sie begann gegen 18:00 MEZ).

Der "bit.ly"-User "benbu", der diesen Link einrichtete, hat bereits 15 weitere Bitlinks/Short-URL erstellt (die seit dem 2. März 2015 aktiv sind).

Zahl der BitlinksZiel/Kampagne
6DailyDates (diese Kampagne)
1Billige Kredite/Kreditkarten
8Coupons

Spam ist ein allgemeines Problem, und zwar nicht nur E-Mail-Spam. Obwohl SMS-Spam in Asien verbreiteter, in Europa aber weniger verbreitet ist.

Schaut man sich andere Kampagnen dieses Users an, so sieht man, dass nicht alle erfolgreich waren. Neben der hier beschriebenen hatten noch 6 weitere einige Klicks. Alle griffen hauptsächlich deutsche Nutzer an.

Erstellt amZiel/KampagneKlicks
02.03.2015Coupons2630
02.03.2015Coupons1764
02.03.2015Coupons250
02.03.2015DailyDates993
03.03.2015Coupons1878
03.03.2015Coupons1004

Klicken Sie ganz generell nicht einfach auf jeden Link, den Sie erhalten, denn es könnte sich schädlicher Content dahinter verbergen. Um den Schutz Ihres mobilen Geräts (Smartphone/Tablet) zu verbessern, führen Sie regelmäßige Updates durch. Außerdem sollten Sie Sicherheitssoftware zum Schutz vor mobiler Malware auf Ihrem Gerät installieren.

Wie Online-Schwindel funktioniert: Betrüger auf Websites mit privaten Kleinanzeigen


  David Jacoby        9 Mrz 2015 | 12:00  MSK

Ihr Kommentar  

Derzeit haben wir in Schweden ein großes Problem mit Betrügern, die versuchen Artikel zu kaufen, die auf verschiedenen Auktionswebsites angeboten werden. Doch wenn man als Anbieter Kontakt zu dem potentiellen Käufer aufnimmt, wird es unschön und man läuft Gefahr, Geld zu verlieren. Das ist im Prinzip nichts Neues und die Internet-Auktionshäuser haben über dieses Problem geschrieben, um ihre Nutzer darüber zu informieren, aber sie erklären dabei nicht im Detail, wie dieser Betrug eigentlich funktioniert – in ihren FAQs raten sie den Usern nur, vorsichtig zu sein. Ich weiß, dass viele Fragen besorgter Anwender unbeantwortet bleiben.

Als einer dieser Verbrecher versuchte, meine Frau zu betrügen, beschloss ich, den Betrug zurückzuverfolgen und den gesamten Prozess zu dokumentieren, damit ich nicht nur die Strafverfolgungsbehörden, sondern auch unsere Leser informieren könnte, wie dieser Schwindel tatsächlich funktioniert. Denn wenn man weiß, wie der Betrug funktioniert, ist es wesentlich einfacher, ihn zu erkennen und zu vermeiden, hinters Licht geführt zu werden.

Zunächst einmal die Hintergrundgeschichte:

Unsere Tochter hat ein neues Fahrrad bekommen, und daher beschlossen wir, ihr altes auf Blocket zu verkaufen, der größten Website für private Anzeigen (kaufen/verkaufen) in Schweden.

Nach ein paar Tagen erhielt meine Frau eine SMS (die unglücklicherweise gelöscht wurde). Die SMS kam von einer polnischen Nummer, und der Absender schrieb in sehr gutem Englisch. Der Absender schrieb, er wäre sehr interessiert an dem Rad, aber er hätte gern mehr Informationen und gab meiner Frau daher eine E-Mail-Adresse. Ich bat sie, NICHT per SMS, sondern via E-Mail zu antworten, da die Übeltäter manchmal SMS von Premiumnummern senden. Das bedeutet, wenn man auf eine solche SMS antwortet, kostet das sehr viel mehr als eine normale SMS.

Ich bat meine Frau, sich bei ihrer Antwort sehr kurz zu fassen. Was sie auch tat, wie an ihrer ersten E-Mail-Antwort unten zu sehen ist:

Wie man sieht, stellt die Person nun stichhaltige Fragen zu dem Fahrrad – es kann sich also nicht um einen Bot handeln, sondern jemand hat tatsächlich manuell auf diese Anzeige geantwortet. Ich habe keine Ahnung, nach welchen Kriterien die Opfer ausgewählt werden, aber es ist offensichtlich ein manueller Prozess.

Wir beschlossen weiterzumachen, um auch den nächsten Schritt im Betrugsschema beobachten zu können, also antworteten wir mit Informationen über das Rad – es bestand auch immerhin noch eine Chance, dass es sich nicht um einen Betrüger handelte, und die Person tatsächlich das Fahrrad kaufen wollte.

Und nach dieser E-Mail begann es dann unschön zu werden. Unser Angebot wurde akzeptiert, doch merkwürdig war, dass der Absender seine polnische Identität bestätigte. Auch wenn man diese Person in sozialen Medien sucht, scheint sie polnischer Herkunft zu sein. Also machten wir weiter.

Die Person fragte nach unserem Namen, den PayPal-Daten und dem Gesamtpreis, den wir aber bereits genannt hatten. Es hieß auch, dass die Versandkosten für das Fahrrad von ihr übernommen würden und auch um das Lieferunternehmen wurde sich gekümmert.

Wir gaben unsere Informationen weiter und warteten auf eine Antwort. Die Betrüger haben SEHR schnell auf alle E-Mails geantwortet; es hatte beinahe den Anschein, als würden dort viele Leute mit Zugriff auf denselben Account sitzen, aber das konnten wir nicht bestätigen. In der E-Mail, die sie direkt vor dem Geldtransfer schickten, gaben sie auch eine Adresse in Polen an. Diese Adresse wurde nicht bestätigt, doch wir versuchen herauszufinden, wer unter der Adresse auf dem unten stehenden Screenshot lebt. Innerhalb von Minuten bestätigten die Absender, dass der Transfer nun abgeschlossen sei, wie auf dem zweiten Screenshot zu sehen ist.

Ich bekam zwei E-Mails von irgendetwas, das wie PayPal aussah, doch bei genauerem Hinschauen erkennt man, dass diese E-Mail keinesfalls von PayPal stammt. Das ist ein sehr schlauer, aber gängiger Trick, der auch bei Phishing-Attacken eingesetzt wird. Guckt man sich die Absenderadresse an, so fällt auf, dass die Mail in Wirklichkeit von service@e-pay-team.com verschickt wurde, was bei Google Mail gehostet wird. Was diese E-Mail so interessant macht, ist die Tatsache, dass sie aller Wahrscheinlichkeit nach ebenfalls manuell erstellt wurde, da sie bestimmte Details enthält, wie etwa den Preis, den wir für das Rad verlangt haben.

Zu diesem Zeitpunkt war kein Geld auf mein PayPal-Konto überwiesen worden – die E-Mails waren nur ein Fake. Die Betrüger versuchten nun, mich dazu zu bringen, die Versandkosten von unserem Konto auf das Konto der Firma „P.S.S Logistics” zu überweisen, in diesem Fall 1.700 Schwedische Kronen (ungefähr 200 Dollar). Der von ihnen ausgewählte Überweisungsprozess sah einen Besuch bei einer Western Union Niederlassung vor, um dort das Geld an diesen Spediteur zu überweisen. Wenn man sich die E-Mails, die die Betrüger schickten, einmal genauer anschaut, bemerkt man, dass wir das Geld an eine Privatperson transferieren sollten. Es gibt eine Firma mit dem Namen “P.S.S Logistics”, aber die ist in Südafrika registriert, und die Betrüger benutzten ihren Namen. Doch wenn man das Geld überweist, geht es an eine Person in Nigeria mit dem Namen “Bamise Seon”.

An dieser Stelle fragte ich mich, ob die Betrüger mit gehackten Accounts arbeiten, denn alle diese Personen findet man in verschiedenen sozialen Netzwerken. Die Person beispielsweise, in deren Namen, der polnisch ist und “Pawel Dylewski” lautet, die E-Mails verschickt wurden, ist bei Google Plus zu finden. Und die Person in Nigeria findet man auf Facebook. Guckt man sich die Screenshots, die ich bei Facebook gemacht habe, genauer an, sieht man, dass es sich um zwei Identitäten handelt, eine männliche und eine weibliche, und dass sie über denselben Namen miteinander verbunden sind. Auf dem Screenshot unten sieht man deutlich, dass dort steht: “Send HER a friend request”, zu Deutsch also „Schicke IHR eine Freundschaftsanfrage“, was darauf schließen lässt, dass dieses Profil zu einer weiblichen Person gehört. Man sieht auch, dass sie einen Freund hat, eine Person, die denselben Namen trägt, aber mit dem Profilfoto eines Mannes und mehr Informationen ausgestattet ist.

Ich arbeite derzeit mit PayPal, Western Union, Google und Strafverfolgungsbehörden zusammen, um die Erkenntnisse, die ich gewonnen habe, zu teilen. Aber ich möchte auch diese Geschichte teilen. Wir müssen jeden informieren, der aktiv Dinge online verkauft oder kauft, damit jeder ein wachsames Auge auf die Details hat. Wenn ein Geschäft zu gut klingt, um wahr zu sein, dann ist es das in den meisten Fällen auch.

Das Schema in Kurzform:

  1. Man erhält eine SMS von einem potentiellen Käufer, die eine E-Mail-Adresse für weitere Korrespondenz enthält.
  2. In einigen Fällen wird die SMS von einer Premiumnummer gesendet, und wenn man darauf antwortet, muss man für den Premium-Service bezahlen.
  3. Wird eine E-Mail-Konversation begonnen, so will der Käufer mit einem Online-Bezahldienst zahlen – zum Beispiel PayPal - und zwar den vollen Preis inklusive Versandkosten.
  4. Die Betrüger verschicken GEFÄLSCHTE E-Mails, die angeblich von PayPal stammen, in denen es heißt, das Geld sei auf Ihr Konto angewiesen worden, würde aber erst nach Abschluss des Geschäfts auf Ihr Konto transferiert.
  5. Das Geschäft kann nur abgeschlossen werden, wenn Sie die Versandkosten an die Spedition überweisen, beispielsweise über Western Union.
  6. Die Spedition gibt es nicht, es handelt sich tatsächlich um das persönliche Konto des Betrügers. Das bedeutet, die Verbrecher wollen Sie dazu bringen, eine Summe aus eigener Tasche zu überweisen, in der Hoffnung, dass Sie dann den vollen Betrag (inklusive den Preis für den Artikel) auf Ihr PayPal-Konto erhalten.

Einige nützliche Tipps für die Kommunikation mit Fremden über das Internet:

  • Bitte kommunizieren Sie nicht via SMS, da Betrüger Premiumnummern verwenden könnten, um ihnen eine Menge Geld abzubuchen.
  • Bitte überprüfen sie jede E-Mail-Adresse mehrfach: In diesem Fall stammte die Mail nicht von“paypal.com”, sondern von “e-pay-team.com”.
  • Überweisen Sie nie irgendwelches Geld an irgendwen; und stellen Sie immer sicher, dass Sie die Zahlung erhalten haben, BEVOR Sie den zu verkaufenden Artikel versenden.
  • Zahlen Sie nie mit Kreditkarte, wenn Sie sich nicht 100%ig sicher sind, dass die Website legitim ist; versuchen Sie sichere Zahlungsmethoden zu verwenden, wie z.B. PayPal.

P.S.: Wir haben das Fahrrad heute verkauft. An eine REALE Person :).

Online-Bedrohungen für Kinder: Die Gefahr ist real


  Kaspersky Lab        4 Mrz 2015 | 14:00  MSK

Ihr Kommentar  

 Download Full Report PDF (eng)

Das Internet ist schon lange keine Domäne der Erwachsenen mehr. Kinder sind heute häufig aktivere Internet-Nutzer als ihre Eltern. Aber ist das World Wide Web auch für Kinder so sicher, dass sie nicht Gefahr laufen, auf unangemessene Inhalte zu stoßen? Um das herauszufinden, haben wir beschlossen, die potenziellen Online-Bedrohungen für Kinder genau zu untersuchen.

Die Untersuchungen basieren auf Daten, die von unserem Kaspersky Security Network verarbeitet wurden. Wir haben die Daten von mehr als einer Million Kaspersky Lab-Kunden analysiert. Jeder von ihnen ist mindestens einmal im letzten Jahr mit gefährlichem Content in Berührung gekommen.

Die Ergebnisse zeigen, dass über die Hälfte (59,5%) unserer Nutzer mit Pornografie konfrontiert wurde; mehr als ein Viertel (26,6%) landete auf Webseiten, die dem Glücksspiel gewidmet sind; jeder fünfte Nutzer geriet auf Seiten mit Waffen und fast dieselbe Zahl kam mit obszöner Sprache in Berührung.

Prozentuale Anteile von Nutzern, die im Jahr 2014 mit gefährlichem Content in Berührung kamen

Webseiten, die diese Art von unangemessenem Content beinhalten (nicht jugendfreie Inhalte, Glücksspiel, Waffen), wurden neben solchen, die Drogen, Tabak und Alkohol zum Inhalt haben, am häufigsten von den Schutzlösungen von Kaspersky Lab blockiert. Die Häufigkeit der Detektionen zeigt, wie schnell es vorkommen kann, dass Nutzer online mit derartigem Content in Berührung kommen.

Zwei Drittel der Nutzer (67,29%) hatten mit Chat-Diensten zu tun. Nur ein sehr kleiner Teil dieser Services, wie z.B. solche mit Anonymitätsfunktion oder mit überwiegend erwachsenen Abonnenten, stellen eine potenzielle Gefahr für Kinder dar. Daher ist es problematisch, Kontakte mit Chat-Services allgemein als ein geltendes Kriterium für eine bestimmte Risikostufe für junge Menschen auszuwählen. Die Daten bestätigen allerdings die Beliebtheit von Chats – und je größer die Popularität eines Chat-Services in einem gewissen Land, desto größer ist die Wahrscheinlichkeit, dass Kinder zufällig oder sogar absichtlich in eine unsichere Chat-Umgebung gelangen. Wenn schon sonst nichts, so könnte der Beweis häufiger Berührungen mit Chat-Diensten ein Zeichen für Eltern sein, der Natur dieser Services größere Aufmerksamkeit zu schenken und zu überdenken, wie wahrscheinlich es ist, dass ihre Kinder dort hineingezogen werden.

Geografisch betrachtet schlug die Kindersicherung in China, den USA, Deutschland, in Großbritannien und in Russland am häufigsten Alarm. Frankreich, Vietnam, Brasilien und Algerien waren ebenfalls unter den ersten zehn Ländern im Ranking nach Detektionen von unangemessenem Content, sie waren aufgrund einer geringeren Detektionshäufigkeit allerdings relativ sicherer.

Jedes der am stärksten betroffenen Länder aus den Top 10 hat hinsichtlich der vorherrschenden Online-Bedrohungen für Kinder seine eigenen, individuellen Charakteristika. So waren beispielsweise nicht jugendfreie Inhalte die größte Bedrohung für junge Nutzer in Deutschland (mit 172 Detektionen pro User), in China (144,18 Detektionen pro User) und in den USA (126,16 Detektionen). Inhalte mit Bezug auf Alkohol, Tabak und Drogen waren eine große Bedrohung für Nutzer aus Russland, Deutschland, den USA und Frankreich. Die Detektionshäufigkeit war in diesen Ländern besonders hoch. Diese Art von Inhalten ist ebenfalls in Brasilien und Großbritannien populär.

Die Tatsache, dass sich die Bedrohungslandschaft für Kinder von Land zu Land entscheidend verändert, ist eine der bemerkenswertesten Erkenntnisse, die aus unserer Studie hervorgegangen sind. Es ist ein klares Zeichen für Eltern auf der ganzen Welt, diesem Aspekt besondere Aufmerksamkeit zu schenken, was ihre Kinder online in ihrem eigenen Land tun, da wir es weltweit mit unterschiedlichen Situationen zu tun haben. Zum Schutz junger Menschen empfehlen wir Erwachsenen, Sicherheitslösungen mit Kindersicherungstechnologien auszuwählen, und umfassenden Gebrauch von sicheren „Kinder“-Modi in Suchmaschinen-Apps zu machen, die Zugriff auf Multimedia-Content ermöglichen und von Kindern genutzt werden.

Doch obgleich Kindersicherungstechnologien Zugriff auf Webseiten mit für Kinder gefährlichem oder verstörendem Content blockieren können, können sie in manchen Situationen keinen verlässlichen Schutz bieten, z.B. im Fall von Cyber-Mobbing oder wenn per Standardeinstellung sichere Webservices, wie etwa soziale Netzwerke oder Chats, von Verbrechern missbraucht werden.

Internet-Sicherheit muss ebenso ernst genommen werden wie die physische Sicherheit im realen Leben. Daher bitten wir alle Eltern dringend, aktiv sowohl am realen als auch am digitalen Leben ihrer Kinder teilzunehmen. Nur dann können sie sicher sein, dass sie den Augenblick nicht verpassen werden, in dem ihr Kind ihre Hilfe benötigen könnte.

In dem vollständigen Text unserer Studie erfahren Sie mehr über Online-Bedrohungen für Kinder.

The Great Bank Robbery: Die große Carbanak-APT


  Global Research and Analysis Team of Kaspersky Lab       16 Februar 2015 | 19:20  MSK

Ihr Kommentar  

Download Full Report PDF (eng)

Die Geschichte von Carbanak begann, als eine ukrainische Bank uns um Hilfe bei forensischen Ermittlungen bat. Auf mysteriöse Weise war Geld von Geldautomaten gestohlen worden. Unser erster Verdacht ging in Richtung des Schadprogramms Tyupkin. Doch bei der Untersuchung der Festplatte des Geldautomaten konnten wir nichts außer einer merkwürdigen VPN-Konfiguration finden (die Netzmaske war auf 172.0.0.0 gestellt).

Zu der Zeit sahen wir es einfach als eine weitere Malware-Attacke an. Damals konnten wir noch nicht ahnen, dass einer unserer Kollegen mitten in der Nacht, um 3 Uhr morgens, einen Telefonanruf erhalten würde. Am Apparat war ein Account-Manager, der uns bat, dringend eine bestimmte Nummer anzurufen. Die Person am anderen Ende der Leitung war der CSO einer russischen Bank. Eines ihrer Systeme warnte, dass Daten von ihrem Domain Controller in die Volksrepublik China gesendet würden.

Vor Ort konnten wir schnell die Malware im System finden. Wir schrieben ein Batch-Script, das die Malware von einem infizierten PC entfernte und führten dieses Script auf allen Computern der Bank aus. Das wiederholten wir mehrfach, bis wir sicher sein konnten, dass alle Rechner sauber waren. Selbstverständlich wurden Samples behalten und durch sie trafen wir das erste Mal auf die Carbanak-Malware.

Modus Operandi

Weitere forensische Analysen führten uns schließlich zur Erstinfektion: Eine Spear-Phishing-Mail mit einem Anhang im Format CPL; obgleich in anderen Fällen Word-Dokumente verwendet wurden, die bekannte Sicherheitslücken ausnutzen. Nach der Ausführung des Shellcodes wird eine auf Carberp basierende Backdoor im System installiert. Diese Backdoor ist heute als Carbanak bekannt. Sie ist ausgerichtet auf Spionage, Datendiebstahl und Remote-Kontrolle.

Sobald die Angreifer in das Netzwerk des Opfers vorgedrungen sind, spähen sie das Netz manuell aus, versuchen, wichtige Computer zu kompromittieren (wie zum Beispiel den des Administrators) und verwenden Lateral-Movement-Tools. Kurz gesagt – sobald sie sich Zugriff verschafft haben, springen sie durch das Netzwerk, bis sie gefunden haben, was sie interessiert. Was genau das ist, kann von Angriff zu Angriff unterschiedlich sein. Sie alle haben allerdings gemeinsam, dass es von diesem Punkt an möglich ist, Geld von der angegriffenen Organisation zu stehlen.

Die Bande hinter Carbanak muss nicht zwangsweise vorherige Kenntnisse über die internen Abläufe jeder angegriffenen Bank haben, da diese von Organisation zu Organisation variieren. Um also zu verstehen, wie eine bestimmte Bank arbeitet, wurden infizierte Computer benutzt, um Videos aufzunehmen, die dann an die Command und Control-Server geschickt wurden. Auch wenn die Qualität der Videos recht schlecht war, waren sie für die Angreifer doch ausreichend, um zu verstehen, was das Opfer tut. Ergänzend waren die Angreifer nämlich auch mit den von einem bestimmten Rechner abgefangenen Tastatureingaben ausgerüstet. So statteten sie sich mit dem Wissen aus, das sie benötigten, um das Geld einzukassieren.

Abhebeprozedur

Im Laufe unserer Ermittlungen stießen wir auf mehrere Methoden, Geld abzukassieren:

Geldautomaten wurden aus der Ferne angewiesen, Geld auszugeben, ohne dass eine Interaktion mit dem Automaten selbst nötig wäre. Das Bargeld wurde dann von Kurieren eingesammelt. Das SWIFT-Netzwerk wurde benutzt, um Geld von der Organisation auf die Konten der Verbrecher zu überweisen. Daneben wurden Datenbanken mit Kontoinformation manipuliert, so dass gefälschte Konten mit einem relativ hohen Kontostand erstellt werden konnten, wobei wieder Kurierdienste zum Einsammeln des Geldes in Anspruch genommen wurden.

Infektionen und Verluste

Seit Beginn unserer Ermittlungen dieser Kampagne haben wir sehr eng mit den Strafverfolgungsbehörden zusammengearbeitet, die die Carbanak-Bande verfolgen. Aufgrund dieser Zusammenarbeit wissen wir, dass mehr als 100 Ziele angegriffen wurden. Was die angegriffenen Finanzinstitutionen betrifft, so gelang es den Kriminellen in mindestens der Hälfte der Fälle, Geld von den infizierten Organisationen zu stehlen. Die Verluste pro Bank liegen zwischen 2,5 Millionen Dollar und ungefähr10 Millionen Dollar. Doch laut den Informationen der Strafverfolgungsorgane und der Opfern selbst könnten die finanziellen Verluste insgesamt bei 1 Milliarde Dollar liegen, was diese Cybercrime-Kampagne zu einer der erfolgreichsten aller Zeiten machen würde.

Unsere Ermittlungen begannen in der Ukraine und verlagerten sich dann nach Moskau, wobei sich die meisten der von der Gruppe angegriffenen Finanzinstitutionen in Osteuropa befinden. Doch dank der KSN-Daten und der aus den Command und Control-Servern erhaltenen Daten wissen wir, dass Carbanak auch Opfer in den USA, Deutschland und China angreift. Nun weitet die Gruppe ihre Operationen auf neue Gebiete aus. Dazu gehören Malaysia, Nepal, Kuwait und verschiedene afrikanische Regionen – unter anderen.

Die Gruppe ist nach wie vor aktiv und wir fordern alle Finanzorganisationen eindringlich auf, ihre Netzwerke sorgfältig auf die Präsenz von Carbanak zu prüfen. Wird die Malware gefunden, muss das Eindringen umgehend den Strafverfolgungsbehörden gemeldet werden.

Eine vollständige Beschreibung der Kampagne, der Infektionssymptome (IOCs) sowie eine Liste der Infektionen finden Sie in unserem Bericht.

Um zu überprüfen, ob Ihr Netzwerk von Carbanak befallen ist, können Sie auch die hier verfügbare offene IOC-Datei mit den Indikatoren für eine Kompromittierung verwenden.


FAQ

Was ist Carbanak?

Carbanak ist der Name, den wir für eine APT-artige Kampagne benutzen, die Finanzinstitutionen angreift (jedoch nicht darauf beschränkt ist). Der wichtigste Unterschied zu anderen APT-Attacken liegt darin, dass die Angreifer nicht Daten, sondern Geld als ihr Hauptziel anvisieren. Wir sagen APT-artig, obwohl die Attacke streng genommen nicht „Advanced“, also fortschrittlich, zu nennen ist. Streng genommen ist die Hauptcharakteristik, die den Angriff definiert, „Persistence“, also Beständigkeit/Beharrlichkeit.

Wir haben die Backdoor Carbanak getauft, da sie auf Carberp basiert und der Name der Konfigurationsdatei "anak.cfg" lautet.

Welche bösartigen Ziele verfolgt diese Kampagne?

Die Angreifer unterwandern das Netzwerk des Opfers und suchen nach dem kritischen System, das sie für die Auszahlung des Geldes nutzen können. Sobald sie eine beträchtliche Summe gestohlen haben (zwischen 2,5 und 10 Millionen US-Dollar pro Organisation), kehren sie dem Opfer den Rücken.

Warum ist Kaspersky Lab der Meinung, dass diese Kampagne von Bedeutung ist?

Finanzinstitutionen waren schon immer ein primäres Ziel Cyberkrimineller. Doch meistens wurden sie über ihre Kunden angegriffen. In diesem Fall richten sich die Angreifer mit einer beispiellosen, zielstrebigen, hochprofessionellen und koordinierten Attacke direkt gegen die Finanzorganisationen, und sie nutzen alle Instrumente des Ziels, um so viel Geld wie nur möglich abzukassieren, bis hin zu einem offensichtlich selbst auferlegten Limit.

Lässt sich der zeitliche Verlauf der Kampagne beschreiben?

Soweit wir wissen, wurden die ersten schädlichen Samples im August 2013 erstellt, als die Cyberkriminellen begannen, die Carbanak-Malware zu testen. Die ersten Infektionen wurden im Dezember 2013 detektiert.

Durchschnittlich wurden für jeden Banküberfall zwei bis vier Monate benötigt, von der Infektion des ersten Computers im Unternehmensnetzwerk der Bank bis hin zum Abheben des Geldes.

Wir glauben, dass die Bande ihre ersten Opfer erfolgreich in der Zeit von Februar bis April 2014 bestohlen hat. Die meisten Infektionen wurden im Juni 2014 registriert.

Aktuell ist die Kampagne noch immer aktiv.

Warum hat Kaspersky Lab nicht schon früher über die Kampagne berichtet?

Seit Beginn unserer Untersuchungen dieser Kampagne arbeiten wir mit verschiedenen Strafverfolgungsbehörden zusammen, die an den Ermittlungen beteiligt sind, und wir haben ihnen so viel wie möglich geholfen. Da es sich um laufende Ermittlungen handelt, wurden wir gebeten, so lange keine Informationen preiszugeben, bis es sicher wäre, dies zu tun.

Wurde Kontakt zu den Opfern und den Computer Emergency Response Teams (CERTs) in den Ländern aufgenommen, in denen Vorfälle registriert wurden?

Ja, die Ermittlungen wurden zu einer gemeinsamen Operation des Global Research and Analysis Teams von Kaspersky Lab und internationalen Organisationen, nationalen und regionalen Strafverfolgungsbehörden und einer Reihe von Computer Emergency Response Teams (CERTs) weltweit.

Eines unserer Hauptziele bestand darin, unser Wissen über die Kampagne und die Infektionssymptome allen identifizierten und potenziellen Opfern mitzuteilen. Wir nutzten die CERTs und Strafverfolgungsbehörden als Verbreitungskanäle.

Wie hat Kaspersky Lab zu den Ermittlungen beigetragen?

Wir unterstützen bei den Ermittlungen und der Bereitstellung von Gegenmaßnahmen, die Malware-Operationen und cyberkriminelle Aktivität stoppen. Während der Ermittlungen haben wir unsere technische Expertise zur Verfügung gestellt, so wie z.B. die Analyse von Infektionsvektoren, Schadprogrammen, die Analyse der unterstützten Command & Control-Infrastruktur und der Ausnutzungsmethoden.

Wie wurde die Malware verbreitet?

Die Angreifer sendeten Spear-Phishing-Mails mit schädlichen Anhängen an die Mitarbeiter der anvisierten Finanzorganisationen, in manchen Fällen haben sie diese an die persönlichen E-Mail-Adressen der Angestellten geschickt. Wir glauben, dass die Angreifer außerdem Drive-by-Download-Attacken eingesetzt haben, aber diese Annahme ist noch nicht zu 100% bestätigt.

Welche potenziellen Auswirkungen hat die Kampagne auf die Opfer?

Basierend auf den Summen, die bisher gestohlen wurden, hat ein neues Opfer Verluste von bis zu 10 Millionen US-Dollar zu erwarten. Doch diese Zahl fußt nur auf dem, was wir bisher wissen: Die potenziellen Verluste einer infizierten Organisation sind nach oben offen.

Wer sind die Opfer? Welches Ausmaß hat die Attacke?

Bei den Opfern handelt es sich in erster Linie um Institutionen aus der Finanzbranche. Allerdings haben wir auch Spuren von Infektionen in POS-Terminals und bei PR-Agenturen gefunden. Um eine Vorstellung vom Ausmaß der Attacke zu bekommen, werfen Sie bitte einen Blick auf die verschiedenen Tabellen und Karten in unserem Bericht.

Wie im Falle vieler Malware-Kampagnen gibt es eine Vielzahl von Unternehmen/Einzelpersonen, die die Malware analysieren, was in Anfragen an den Command und Control-Server mündet. Wenn wir diese Server analysieren, sehen wir nur die IPs und möglicherweise einige zusätzliche Informationen. Gibt es keine solchen zusätzlichen Informationen und die IP kann nicht zu ihrem Besitzer zurückverfolgt werden, markieren wir das als eine Infektion.

Basierend auf diesem Ansatz bringt uns unsere Analyse zu dem Schluss, dass die nach Anzahl der Infektionsspuren (IP-Adressen) am stärksten betroffenen Länder Russland, die USA, Deutschland und China sind.

Wie sind Unternehmensanwender vor dieser Art von Attacke geschützt? Schützt Kaspersky Lab seine Nutzer?

Ja, wir detektieren Carbanak-Samples als Backdoor.Win32.Carbanak und Backdoor.Win32.CarbanakCmd.

Alle Produkte für Unternehmen und Unternehmenslösungen von Kaspersky Lab detektieren die Carbanak-Samples. Um das Schutzniveau noch zu erhöhen, wird empfohlen, das Proaktive Schutzmodul von Kaspersky Lab zu aktivieren, das in jedem modernen Produkt und in jeder Lösung enthalten ist.

Hier noch einige allgemeine Empfehlungen:

  • Öffnen Sie keine verdächtigen E-Mails, insbesondere dann nicht, wenn sie einen Anhang haben;
  • Aktualisieren Sie Ihre Software (bei dieser Kampagne wurden keine Zero-Day-Schwachstellen ausgenutzt);
  • Aktivieren Sie in Ihren Schutzlösungen die heuristischen Erkennungsmethoden, denn dann ist es wahrscheinlicher, dass solche neuen Samples detektiert und von vornherein gestoppt werden.

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

Nach oben  |  Archiv >>

 

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

Email: webmaster@kaspersky.com
Datenschutzbestimmungen