|
Diskussionsforum: Ebenfalls .lockyWindows 7 Hier sind ausschließlich fachspezifische Diskussionen erwünscht. Bitte keine Log-Files, Hilferufe oder ähnliches posten. Themen zum "Trojaner entfernen" oder "Malware Probleme" dürfen hier nur diskutiert werden. Bereinigungen von nicht ausgebildeten Usern sind hier untersagt. Wenn du dir einen Virus doer Trojaner eingefangen hast, eröffne ein Thema in den Bereinigungsforen oben. |
16.02.2016, 12:19 | #1 |
| 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. |
16.02.2016, 12:50 | #2 |
/// Winkelfunktion /// TB-Süch-Tiger™ | Ebenfalls .locky Moin
__________________und was sollen wir jetzt tun? Die verschlüsselten Dateien können wir auch nicht entschlüsseln.
__________________ |
16.02.2016, 12:58 | #3 |
| Ebenfalls .locky 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. |
16.02.2016, 13:19 | #4 |
/// Winkelfunktion /// TB-Süch-Tiger™ | Ebenfalls .locky Du kannst die VM plattmachen und aus dem letzten Backup wiederherstellen
__________________ Logfiles bitte immer in CODE-Tags posten |
16.02.2016, 13:30 | #5 |
| Ebenfalls .locky 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. |
16.02.2016, 13:42 | #6 |
/// Winkelfunktion /// TB-Süch-Tiger™ | Ebenfalls .locky 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? Aber ja, wer solche Paranoia hat kann ja gerne auch alle Clients neu installieren
__________________ --> Ebenfalls .locky |
16.02.2016, 14:20 | #7 | |
| Ebenfalls .lockyZitat:
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. |
16.02.2016, 14:28 | #8 |
/// Winkelfunktion /// TB-Süch-Tiger™ | Ebenfalls .locky 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.
__________________ Logfiles bitte immer in CODE-Tags posten |
16.02.2016, 14:51 | #9 |
| Ebenfalls .locky 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. |
16.02.2016, 15:09 | #10 | |
/// Winkelfunktion /// TB-Süch-Tiger™ | Ebenfalls .lockyZitat:
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.
__________________ Logfiles bitte immer in CODE-Tags posten |
16.02.2016, 21:24 | #11 |
| Ebenfalls .locky 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. |
16.02.2016, 21:34 | #12 | ||
/// Winkelfunktion /// TB-Süch-Tiger™ | Ebenfalls .locky 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 Zitat:
Zitat:
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.
__________________ Logfiles bitte immer in CODE-Tags posten |
17.02.2016, 17:34 | #13 |
| 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 |
18.02.2016, 10:31 | #14 | |
| Ebenfalls .lockyZitat:
Falsch ausgedrückt, natürlich die auf der VM hinterlegten Daten. Das ist aber meine kleinstes Problem. |
18.02.2016, 10:45 | #15 |
/// Winkelfunktion /// TB-Süch-Tiger™ | Ebenfalls .locky Was genau ist denn jetzt dein Problem?
__________________ Logfiles bitte immer in CODE-Tags posten |
Themen zu Ebenfalls .locky |
blöd, board, client, clients, dateien, daten, daten verschlüsselt, ebenfalls, excel, festgestellt, gestellt, gestern, gewisse, gewissen, micro, nicht, nichts, scan, trend, trend micro, verschlüsselte, verschlüsselung, weiteren, weiße |