Ebenfalls .locky
 

Hallo Board,
Eine unserer VM ist ebenfalls von .locky befallen. Wurde gestern ca. 15:50 festgestellt was sich auch mit den Zeitstempeln der verschlüsselten Dateien deckt.
Interessanter weiße, bisher nur Word und Excel Datei, und diese tatsächlich nur auf einer VM und bisher auf keinem Client Rechner. Es wurden auch nicht alle Word und Excel Dateien Verschlüsse.
Diverse Scanns mit Trend Micro auf allen Clients sowie auf der VM hat nichts gebracht.
So blöd sich das anhört, es sieht so aus als ob die Verschlüsselung nur für einen gewissen Zeitraum stattfand. Nach ca. 16:00 Uhr wurden keine weiteren Daten verschlüsselt.

Moin :kaffee:

und was sollen wir jetzt tun? Die verschlüsselten Dateien können wir auch nicht entschlüsseln.

��Schon klar, evtl. hilft es euch ja weiter wenn mehr Infos zum Befallen bekannt werden.

Arg viel lässt sich momentan im Internet nicht dazu finden. Vorallem finde ich derzeit keine Möglichkeit den Schädling aufzufinden.
Vorher kann ich kein Backup einspielen.
An der VM (Fileserver) hängen 25 Arbeitsplätze welche auf die Dateien angewiesen sind.

Du kannst die VM plattmachen und aus dem letzten Backup wiederherstellen :D

:applaus:Ah ja, wenn ich wüste wo der Trojaner, Virus Dingsbums sitzt - ja.
Unser Backup ist auf einer externen NAS. Solange ich nicht weiß
wie sich das entwickelt, bzw. wo er sich eingenistet hat, wird ich die NAS nicht wieder
ins Netzwerk hängen.

Viel hilfreiche wäre zu wissen um was es sich handeln könnte.
Momentan tippe ich auf TeslaCrypt 3.0 allerdings ist bei der Variante 3.0 die
Dateiendung .locky bisher nicht bekannt.

Das Teil verschlüsselt bei Ausführung.

Glaubst du das Ding richtet sich als Service irgendwo ein und monitored all deine shares auf unverschlüsselte Files? :rofl: :applaus:

Aber ja, wer solche Paranoia hat kann ja gerne auch alle Clients neu installieren ;)

Na ja mit Paranoia hat das nicht zu tun.
Bis vor 10 Minuten war eben noch nicht klar wo er ist, bzw. warum er nur
auf unseren Fileserver zugegriffen hat.
Offensichtlich wäre er in diesem Fall eben nicht über einen Client rein gekommen.
Bzw. auf diesem Ausgeführt worden.

Wie gesagt, bis vor 10 Minuten.
Soeben hat eine Mitarbeiterin verschlüsselte Dateien auf ihrem lokalen Laufwerk gefunden.
Gestern Abend, hat auf eben diesem PC der Virenscanner nichts gefunden.

Ganz alter Hut, sollte man als Windows-Admin wissen: schauen, wer der Besitzer einer (verschlüsselten) Datei ist. Meistens gibt das Aufschluss darüber und dann lässt sich auch meistens darauf ableiten, von welchem Client das ausging.

Wenn nur der Fileserver betroffen ist, also der ransom auf einem SMB share losing, dann werden hoffentlich die Schattenkopien helfen. Voraussetzung ist natürlich ein Windows-Fileserver und min. Windows Server 2008. Und natürlich muss man die Schattenkopien auch aktiviert haben.

Wir, eine 120 Kollegen Bude, machen NIX ohne Schattenkopien und täglich Backups aller VMs auf den ESXi Hosts via Veeam.

Natürlich haben wir die Besitzer der verschlüsselten Dateien überprüft,
natürlich ohne Erfolg. Da jeder User auf dem Fileserver die selben schreib/ lese Berechtigungen hat ist das wenig zielführend.

Ebenso haben wir die Client nach verschlüsselten Dateien auf ihren lokalen
Laufwerken überprüft. Und genau da war der Fehler.
Ausgerechnet diese Mitarbeiterin hat absolut keine Excel oder Word Datei
auf ihrem Rechner gespeichert.
Somit konnte der Trojaner dort auch nichts ausrichten.
Erst heute Vormittag hat sie, um überhaupt einen Betrieb aufrecht zu erhalten,
lokal gespeichert.

Kommt natürlich drauf an, welchen Fileserver man hat. Ich müsste auch mal wissen wie genau wer mit welchem Login auf die SMB-Shares geht. Wenn man mit einem Windows-Server einen Share einrichtet und die Kollegen mit ihrem AD-User da raufgehen, dann sieht man das schon.



Das versteh ich nicht. Nur weil die keine Officedatei gespeichert hat, heißt das nicht automatisch, dass sie den Schädling nicht ausgeführt hat. Wenn man den Anhang direkt aus der Mail öffnet, landet die erstmal in %tmp% und wird vllt, vllt auch nicht, nach dem Schließen des Programms, das diese öffnet, auch wieder gelöscht. Wenn sie gelöscht wurde und sonst keine Officedateien drauf hatte wirst du jetzt natülich denken, sie hat keine solchen Dokumente, aber dabei meine erwähnte Möglichkeit vergessen. Und natürlich kann der Schädling auch in einer ZIP gekommen sein, die widerum den Müll in irgendeiner direkt ausführbaren Datei transportierte.

Das ist eigentlich nicht schwierig zu verstehen.
Wenn der VS mangels aktueller Signaturen nichts findet,
und keine Dateien verschlüsselt sind, woher soll ich dann
wissen das der Client die Quelle ist?

Und noch zu den Schattenkopien, nach momentanem Stand der Erkenntniss,
löscht der Schädlng die Schattenkopien.

Wir sichern wöchentlich komplett, und nächtlich incrementel.
Von daher fehlt mit der Montag. Wäre zu verschmerzen.

Nur solange ich den Schädling nicht eingegerenzt und entfent habe,
ich evtl noch davon ausgehen muss, dass er irgendwo im Netzwerk noch vorhanden
ist, werde ich mit Sicherheit nicht auf das NAS Backup zurückgreifen.

Die Aussage dass es Quatsch wäre, dass der Schädling sich auf die NAS ausbreitet
kann nur jemand treffen der den Schädling analysiert oder ihn geschrieben hat.
Alles andere ist mutmaßen, und im Zusammenhang mit der aktualität des Befalls
absolut nicht angebracht.

Im übrigen sehe ich meinen Post nicht als Hilferuf, sondern als Info für den ein oder
anderen der auch nach Anhaltspunkten sucht.

So, ich muss gestehen, dass ich beim heutigen Posting um 15:09 den heise Artikel noch nicht kannte => Erpressungs-Trojaner Locky schlägt offenbar koordiniert zu | heise online

Das stimmt, das geht dann nicht. Höchtens mit so etwas wie proaktiver Erkennung, Überwachung von Clients, dass sich was Neues was in bestimmte Bereiche (services, scheduledtasks etc.pp.) geschrieben hat.


Ja, das haben auch schon Verschlüsselungsviecher letztes Jahr gemacht. Aber das geht ja nur auf der lokalen Kiste wenn man als lokaler Admin das Vieh gestartet hat. Natürlich kann das Vieh auch Dateien in Netzlaufwerken zerstören, aber da löscht es keine Schattenkopien. Dazu muss man schon Adminrechte auf dem Server haben.


Was verstehst du unter ausbreiten? Dass der Schädling dort liegende Dateien in einem SMB-Share verschlüsseln kann ist unstrittig. Hab ich auch schon mal live gesehen, da hat ein anderes Vieh eine Freigabe eines Windows-Servers verschlüsselt. Dort waren die Schattenkopien natürlich NICHT betroffen. Der Schädling klinkt sich nicht ins OS des NAS ein, damit das NAS dann den Schadcode ausführt.

Neuinstallation
 

@rainer205:

welche vm? hyper-v? oder esxi?

das windows-daddelding wird keinen vmware esxi host verschlüsseln können...

wie kommt das? aus hyper-v sollte ja nix auf einer solchen kiste (m.E.) laufen

gruss sepp

vSphere.
Falsch ausgedrückt, natürlich die auf der VM hinterlegten Daten.
Das ist aber meine kleinstes Problem.

Was genau ist denn jetzt dein Problem? :D

Kurz zum Verständnis, ich mach den Admin nebenher (:eek: war klar)
und eigentlich nur für die Clients, Netzwerk, Drucker...
Für die Server haben wir ein Systemhaus.

Um unsere Situation zu Verstehen müsste ich zu weit ausholen,
deshalb nur in Stichworten

-Alter File/ David Mail- Faxserver 6 Jahre alt-

Roadmapp:
1. neuer Server mit VM - 2. Telefonanlage in Cloud - 3. Telefon- Faxmanagement Lösung -
4. Exchange Server - 5. David Migration - 6. David und alten Server abschalten.

Bei 2 und 3 haben wir Probleme mit der Zuverlässigkeit bekommen, was zur Folge hatte,
dass der ganze Prozess ins Stocken geraten ist und bisher nicht sauber zu ende gebracht wurde .
In den Weihnachtsferien ist uns die Hardware mit der ESX abgeraucht, so das wir schnell
Hilfe brauchten. Die ESX wurde wieder hergestellt, leider wurde hierbei eine VM vergessen.
Und genau auf dieser VM lief Veeam :balla:.
Die genauen Hintergründe sind noch etwas komplizierter.
Fakt ist aber, unser Backup ist von Weihnachten :eek:
Aber selbst wenn dieses aktuell gewesen wäre, es hätte vermutlich nicht verwendet werden
können, da die gesicherte Platte in einem Dateisystem formatiert war, welches Veeam nicht
versteht.

Wir sind gerade dabei BitCoins zu kaufen.

Von welchem Filesystem sprichst du da? :confused:

Laut Info von gestern Nacht ist es wohl ReFS.
Laut Info von heute Mittag wohl doch nicht.
Wie gesagt -> Systemhaus :balla:

Ach ja, seit ca. 10 Minuten läuft Locky Decrypter,
die ersten Daten sind wieder da.

https://helpcenter.veeam.com/backup/...m_support.html

Ziemlich clever :cool: :D

Hallo zusammen!

Leider hat es uns auch erwischt: 5 VMs und 3 Hosts. Nachdem es aktuell nicht wirklich eine Möglichkeit gibt die Daten zu rekonstruieren - unsere letzte womöglich sichere Datensicherung ist leider vom 19.02.2016 - wollte ich nachfragen, ob jemand bezahlt, der Decrypter alles freigegeben hat und wie es mit Nacharbeiten aussieht...

Schon einmal vielen Dank!

Es haben schon einige bezahlt und den Schlüssel zur Entschlüsselung dann bekommen. Du kannst aber auch Pech haben und auf Trittbrettfahrer hereinfallen.

Das Risiko liegt nun bei dir, wenn du garnichts bezahlst sind deine Daten auf jeden Fall weg, bezahlst du, kannst du deine Daten wiederbekommen.

Warum sind keine Schattenkopien auf den Windows-Servern aktiviert??? :wtf:

Wenn ich das richtig gesehen habe, dann wurden die Schattenkopieen ausgehebelt. Ich habe vom 19.02.2016 ein Vollbackup (VEEAM), dass ich gerade vom NAS auf eine externe Harddisk kopiere und dann mounten möchte um zu überprüfen, ob die Sicherung befallen ist oder nicht.
Anschließend würden wir entscheiden, ob wir die hoffentlich nicht befallene Sicherung zurückspielen und die Arbeit der letzten Tage verlieren oder bezahlen.

Bezahlen wäre mir eigentlich am liebsten. So erkaufen wir uns Zeit, können weiterarbeiten und vielleicht sind die Antivierenhersteller so weit, dass sie locky rückstandsfrei entfernen können.
Aktuell habe ich hier etwas gefunden:
https://www.xgadget.de/anleitung/anleitung-locky-trojaner-entfernen/
Mehrere Einträge sind bei uns reproduzierbar.

Das Problem an locky ist nicht die Entfernung, sondern seine Verschlüsselungsroutine!

Das ist uns bewußt. Unsere Bedenken sind, dass wir uns freikaufen und unser befallenes System kurze Zeit später wieder von locky reaktiviert und somit verschlüsselt wird. Vielleicht liegen wir hier völlig falsch und locky hat nur verschlüsselt und das war es..

Weitere Frage:
Ich habe mehrere Meinungen bezüglich locky aufgetan:
1. locky hat sich vor einiger Zeit im System vergraben und ist jetzt erst aktiv geworden. Sprich: Sicherungen von vor 5 Tagen sind somit nicht sinnvoll.

2. locky ist nach dem Befall sofort aktiv geworden und hat konvertiert und später sein "Arbeit" gezeigt.

Welcher Punkt passt?

lt. heise war die Infektion schon vorher da, aber locky hat "geschlafen" also zeitgesteuert sein Unheil angerichtet. Das hat den Vorteil für die Erpresser, dass die Admins der betroffenen Systeme so nicht mehr so schnellen herausfinden können, wann und wie genau und das System infiziert wurde.
Die letzten Sicherungen sind alle sinnvoll, das gibt es sicher noch Daten darin die noch nicht verschlüsselt sind. Man muss auch nicht panische hinter jeder Datei eine Manipulation mit bösem eingeschleusten code herbeireden :kaffee:

Bei uns ging es sofort los. User hat sich bei einem URI vertippt und es ging los, bei anderen hat die Bombe getickt. Mit dem Decryptor kommt man wohl wieder an die Daten aber nicht an ein vertrauenswürdiges System.
Wenn die Attacke von einem Client ausging ist die Welt ja noch in Ordnung (wobei dann die Frage wäre wie es eure Hosts zerdeppern kann). Daten wiederherstellen (aus Backup oder vom decryptor), Backup erstellen, dafür sorgen, dass das Backup auch wirklich läuft (min. 1x täglich) und dann ist man gegen das Schlimmste abgesichert.
Wenn die Attacke nicht von einem Standarduser/-client kam habt Ihr eh ein ganz anderes Problem und der nächste Ärger ist vorprogrammiert.

Kurzes Update:
Mittwoch war unser Ausbruch und wir haben vom Dienstag Abend ein Backup aller virtualisierten Server eingespielt.
Aktuell läuft alles sehr gut und wir sind guter Hoffnung. Mein persönliches Bauchgefühl sagt aber leider noch immer: :nono:

Schauen wir mal, dann sehen wir schon.