Gehackter lokaler Server (passwort zurücksetzen nicht möglich)
Hi,
bei einen Kunden ist dessen Windows Server 2012 R2 gehackt worden und mittels randsom-software verschlüsselt worden.
Zusätzlich wurden 2 admin Account angelegt. Alle Benutzerkonten haben hoffensichtlich neue Kennwörter bekommen, sodass man keine Logs sichten kann.
Das war erstmal nicht schwierig zu umgehen.... dachte ich mir zumindest.
Setup DVD und utilman mit cmd austauschen. Der bekannte weg halt.
Wenn ich nun aber die cmd aufrufen dann fragt mich der prompt nach einen Benutzernamen und passwort.
Da ich das schon mehrmals gemacht habe, weiß ich, dass diese Abfrage nicht normal ist. Es KÖNNTE aber auch sein, das das ein Update mitunter unterbunden hatte (und ich auf einen alten Stand bin).
Sprich: erstmal bin ich auf diesen Wege nicht weiter gekommen.
Nun frage ich mich: Was ist, wenn der Hacker die cmd ausgetauscht hat und diesen Weg der Passwort neu setzung zu umgehen ?
Dann würde es doch reichen, wenn ich die cmd.exe von meinen sauberen System nehme und auf den kompr. Server überschreibe ?
Testen tu ich das morgen vor Ort auf alle Fälle mal... nur frage ich mich jetzt: Erzeugt die cmd diese Kennwortabfrage oder vlt. eine Gruppenrichtlinie oder eine andere Datei/Dienst sodass ich in diesen Bereich auf alle Fälle nicht weiterkommen werde ?
Danke schon mal für Tipps oder Erfahurngsberichte
bei einen Kunden ist dessen Windows Server 2012 R2 gehackt worden und mittels randsom-software verschlüsselt worden.
Zusätzlich wurden 2 admin Account angelegt. Alle Benutzerkonten haben hoffensichtlich neue Kennwörter bekommen, sodass man keine Logs sichten kann.
Das war erstmal nicht schwierig zu umgehen.... dachte ich mir zumindest.
Setup DVD und utilman mit cmd austauschen. Der bekannte weg halt.
Wenn ich nun aber die cmd aufrufen dann fragt mich der prompt nach einen Benutzernamen und passwort.
Da ich das schon mehrmals gemacht habe, weiß ich, dass diese Abfrage nicht normal ist. Es KÖNNTE aber auch sein, das das ein Update mitunter unterbunden hatte (und ich auf einen alten Stand bin).
Sprich: erstmal bin ich auf diesen Wege nicht weiter gekommen.
Nun frage ich mich: Was ist, wenn der Hacker die cmd ausgetauscht hat und diesen Weg der Passwort neu setzung zu umgehen ?
Dann würde es doch reichen, wenn ich die cmd.exe von meinen sauberen System nehme und auf den kompr. Server überschreibe ?
Testen tu ich das morgen vor Ort auf alle Fälle mal... nur frage ich mich jetzt: Erzeugt die cmd diese Kennwortabfrage oder vlt. eine Gruppenrichtlinie oder eine andere Datei/Dienst sodass ich in diesen Bereich auf alle Fälle nicht weiterkommen werde ?
Danke schon mal für Tipps oder Erfahurngsberichte
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 347736
Url: https://administrator.de/forum/gehackter-lokaler-server-passwort-zuruecksetzen-nicht-moeglich-347736.html
Ausgedruckt am: 25.12.2024 um 05:12 Uhr
15 Kommentare
Neuester Kommentar
Zitat von @lord-icon:
Du hast gleich mein ersten Satz überlesen:
"... und mittels randsom-software verschlüsselt worden."
Ich muß ein neus Programm draufspielen um ein Log zu erzeugen das ESET sagt, wo das Problem liegt, was passiert ist (sofern ermittelbar) und andere Eckdaten um ein gegentool zu erstellen
Du hast gleich mein ersten Satz überlesen:
"... und mittels randsom-software verschlüsselt worden."
Ich muß ein neus Programm draufspielen um ein Log zu erzeugen das ESET sagt, wo das Problem liegt, was passiert ist (sofern ermittelbar) und andere Eckdaten um ein gegentool zu erstellen
Bevor Du irgendetwas installierst, solltes Du zunächst ein image ziehen und dann mit einer forensischen distribution oder einem forensischen tool die daten analysieren.
Auf das kompromittierte System irgendetwas zu installieren nützt nichts, weil eben die malware alles mögliche machen kann.
Ruf einen Spezialitden, wenn die Kiste analysiert werden muß. Und für das weiterarbeiten im betrieb machst Du ein recovery vom Backup.
lks
lks
Alle Benutzerkonten haben hoffensichtlich neue Kennwörter bekommen, sodass man keine Logs sichten kann.
Diese Aussage erweckt den Eindruck, als wenn eben nicht ALLES verschlüsselt wurde.
Außerdem wird nirgendwo erwähnt, um WELCHE Logs es sich handelt.
Daher bin ich von den lokalen Logs ausgegangen.
Und, wie Lochkartenstanzer schon sagt:
Auf das kompromittierte System irgendetwas zu installieren nützt nichts, weil eben die malware alles mögliche machen kann.
Und bezüglich
um ein gegentool zu erstellen
... mach dir da mal keine großen Hoffnungen.Zitat von @lord-icon:
Zuvor müsste ich aber wissen, ob man über die Gruppenrichtlinen CMD soweit beeinflussen kann, das dort erstmal nach ein passwort gefragt wird.
Zuvor müsste ich aber wissen, ob man über die Gruppenrichtlinen CMD soweit beeinflussen kann, das dort erstmal nach ein passwort gefragt wird.
Mal ein ganz andere frage:
Hast Du das CMD von dem infizierten System genommen oder ein sauberes von einem anderen System? Wie gesagt: Jedes binary auf dem infozierten System ist nicht vertrauenswürdeig!
lks
PS: Hast Du denn überhapt ein offline-Image image von der Platte gezogen? Wenn nciht, solltest Du das jetzt schleunigst nachholen, um bei "Fehlern" den Stand zurücksetzen zu können.
Zitat von @lord-icon:
janein.... auf dem Server lief ACRONIS als Backup Programm
Das Backup vom Server und auch von den Clients wurden per SMB auf den localen NAS gespeichert.
Um ein Standortunabhängiges Backup zu haben, wurde das Backup zusätzlich per SFTP ins RZ verschlüsselt gespeichert.
Beide Backuport sind verschlüsselt worden.
janein.... auf dem Server lief ACRONIS als Backup Programm
Das Backup vom Server und auch von den Clients wurden per SMB auf den localen NAS gespeichert.
Um ein Standortunabhängiges Backup zu haben, wurde das Backup zusätzlich per SFTP ins RZ verschlüsselt gespeichert.
Beide Backuport sind verschlüsselt worden.
Sprich: clever geplant?
Nun, was erhoffst du dir von ESET? Ist die Firma noch arbeitsfähig? Wer haftet (ESET wird das nicht tun)?
Nein, es gibt keine GPO, die nach einem Password fragt. Abgesehen davon wird beim üblichen Verlauf keine GPO mehr ausgerollt. DIe sind nämlich dann wohl auch verschlüsselt. System schon neugestartet?
moin...
aha
Beide Backuport sind verschlüsselt worden.
kaum zu glauben... und unverantwortlich!
Dami ESET VERSUCHEN kann aktiv zu werden, benötigen die einmal den "Erpresserbrief", 1 mal eine verschlüsselte und eine unverschlüsselte Datei mit dem gleichen Stand ... <= bis hier alles vorhanden.... und dann von einen Programm das LOG
was soll ESET deiner meinung nach machen?
was für eine datei endung haben die verschlüsselten Daten?
was für ein AV Program war da am Werk, und hat nix mitbekommen?
Erst wenn diese 4 Dinge vorliegen, fangen die überhaupt an was zu checken.
?
bitte mach ein Image vom System... vorher
ESET wurde mitgeteilt, dass der Server verschlüsselt worden ist. Somit gehe ich davon aus, dass das Wissendlich hingenommen worden ist und das Tool dennoch irgendwas ermittelt. WAS das dann sein wird sei dahingestellt. Zumal die Windows Datein selbst logischerweise unverschlüsselt sind. Auch die beiden programm order sind unverschlüsselt. VLT... aber auch nur vlt sind ein paar Daten ermittelbar.
wer hat was ESET mitgeteilt?
Zuvor müsste ich aber wissen, ob man über die Gruppenrichtlinen CMD soweit beeinflussen kann, das dort erstmal nach ein passwort gefragt wird.
kannst eine saubere Datei einspielen...
dein Gehackter lokaler Server ist zu 99 % durch selbstverschulden in seinem jetzigen zustand! warscheinlich per Mail!
oder steht der mit dem nackten hintern im Inet?
Frank
aha
Das Backup vom Server und auch von den Clients wurden per SMB auf den localen NAS gespeichert.
und keiner kommt auf die idee mal was auf eine USB Platte etc zu schieben?Um ein Standortunabhängiges Backup zu haben, wurde das Backup zusätzlich per SFTP ins RZ verschlüsselt gespeichert.
alle kopien sind verschlüsselt?Beide Backuport sind verschlüsselt worden.
Dami ESET VERSUCHEN kann aktiv zu werden, benötigen die einmal den "Erpresserbrief", 1 mal eine verschlüsselte und eine unverschlüsselte Datei mit dem gleichen Stand ... <= bis hier alles vorhanden.... und dann von einen Programm das LOG
was für eine datei endung haben die verschlüsselten Daten?
was für ein AV Program war da am Werk, und hat nix mitbekommen?
Erst wenn diese 4 Dinge vorliegen, fangen die überhaupt an was zu checken.
Letzteres kann aufgrund des fehlenden Passwort aber nicht erfolgen.
das wäre ja einfach... die Passwörter kannst du selber wieder ändern! ich darf hir nicht schreiben wie, aber google ist ja dein freund!bitte mach ein Image vom System... vorher
ESET wurde mitgeteilt, dass der Server verschlüsselt worden ist. Somit gehe ich davon aus, dass das Wissendlich hingenommen worden ist und das Tool dennoch irgendwas ermittelt. WAS das dann sein wird sei dahingestellt. Zumal die Windows Datein selbst logischerweise unverschlüsselt sind. Auch die beiden programm order sind unverschlüsselt. VLT... aber auch nur vlt sind ein paar Daten ermittelbar.
Zuvor müsste ich aber wissen, ob man über die Gruppenrichtlinen CMD soweit beeinflussen kann, das dort erstmal nach ein passwort gefragt wird.
dein Gehackter lokaler Server ist zu 99 % durch selbstverschulden in seinem jetzigen zustand! warscheinlich per Mail!
oder steht der mit dem nackten hintern im Inet?
Frank
Moin,
ehrlich gesagt - wenn ich das alles richtig verstehe hat $Kunde jetzt kein Backup mehr (da alle Versionen verschlüsselt - schön blöd das alle Backup-Versionen dauerhaft erreichbar sind, das is eigene blödheit!). Und du möchtest jetzt an der letzten verbleibenden Version rumbasteln? Nich schlecht, ich weiss nicht ob mutig oder blöd, aber in jedem fall davon mehr als genug!
Ich würde mir jetzt erst mal nen Image von dem Server ziehen - und NUR darauf arbeiten! Da kannst du mit der CMD rumprobieren - und wenn es schief geht, egal, Image neu drauf, neuer Versuch... Das man das Live-System bereits vom Netz getrennt haben sollte brauch man wohl nicht erwähnen, oder? Denn du weisst ja nicht ob derjenige der die Daten verschlüsselt hat nicht auch bereits die Daten kopiert und/oder fröhlich munter an ein erreichbares Adressbuch versendet.
ehrlich gesagt - wenn ich das alles richtig verstehe hat $Kunde jetzt kein Backup mehr (da alle Versionen verschlüsselt - schön blöd das alle Backup-Versionen dauerhaft erreichbar sind, das is eigene blödheit!). Und du möchtest jetzt an der letzten verbleibenden Version rumbasteln? Nich schlecht, ich weiss nicht ob mutig oder blöd, aber in jedem fall davon mehr als genug!
Ich würde mir jetzt erst mal nen Image von dem Server ziehen - und NUR darauf arbeiten! Da kannst du mit der CMD rumprobieren - und wenn es schief geht, egal, Image neu drauf, neuer Versuch... Das man das Live-System bereits vom Netz getrennt haben sollte brauch man wohl nicht erwähnen, oder? Denn du weisst ja nicht ob derjenige der die Daten verschlüsselt hat nicht auch bereits die Daten kopiert und/oder fröhlich munter an ein erreichbares Adressbuch versendet.
Das soll jetzt nicht herablassend klingen, aber als ENDUSER, mit Schwerpunkt Linux/Unix, solltest du da doch lieber einen (Windows-)Fachmann ran lassen, bevor du nachher mit einem System dastehst, welches hätte gerettet werden können, du es aber leider verbockt hast.
Wie gesagt, nicht böse gemeint!
Was die angewandte Backup-"Strategie" angeht... da wurde eigentlich schon alles gesagt.
Zieh dir auf jeden Fall ein Image von der infizierten Platte, BEVOR du da irgendwas rumbastelst.
Wie gesagt, nicht böse gemeint!
Was die angewandte Backup-"Strategie" angeht... da wurde eigentlich schon alles gesagt.
Zieh dir auf jeden Fall ein Image von der infizierten Platte, BEVOR du da irgendwas rumbastelst.
Hallo,
da stehts doch Linux-Server User. Also so behandeln.
Win zu "reparieren" bringt eh fast nix wenn unbekannte Malware im Spiel ist , Platte putzen + neu aufsetzen!
Datenzugriff über Linux, NTFS mounten und ansehen. IIRR sind da etliche (alle?) Zugriffsrichtlinien ausser Kraft.
Bei den per SFTP gespeicherten Backups würde ich noch mal hinsehen, vorausgesetzt es gab bei jedem Transfer einen neuen Namen, na ja zumindest in vertretbaren Abständen, alternativ waren die Daten unwichtig und mit wenig Aufwand ersetzbar.
Bei SFTP Speicherung im RZ meintest du sicher/hoffentlich: von dir selbst verschlüsselt und du kannst das auch wieder entschlüsseln.
Datenlabore könnten evtl. Helfen beim Entschlüsseln der Serverplatte - brauchen aber oft die ganze Platte dazu.
Ach ja... und die infizierte Platte sollte nicht mit dem Netzwerk in Verbindung kommen, wie auch der Untersuchungsrechner!
Fred
da stehts doch Linux-Server User. Also so behandeln.
Win zu "reparieren" bringt eh fast nix wenn unbekannte Malware im Spiel ist , Platte putzen + neu aufsetzen!
Datenzugriff über Linux, NTFS mounten und ansehen. IIRR sind da etliche (alle?) Zugriffsrichtlinien ausser Kraft.
Bei den per SFTP gespeicherten Backups würde ich noch mal hinsehen, vorausgesetzt es gab bei jedem Transfer einen neuen Namen, na ja zumindest in vertretbaren Abständen, alternativ waren die Daten unwichtig und mit wenig Aufwand ersetzbar.
Bei SFTP Speicherung im RZ meintest du sicher/hoffentlich: von dir selbst verschlüsselt und du kannst das auch wieder entschlüsseln.
Datenlabore könnten evtl. Helfen beim Entschlüsseln der Serverplatte - brauchen aber oft die ganze Platte dazu.
Ach ja... und die infizierte Platte sollte nicht mit dem Netzwerk in Verbindung kommen, wie auch der Untersuchungsrechner!
Fred
Zitat von @lord-icon:
Ablauf: Kundenterin Montag früh. Server war Kundenseitig schon ausgeschalten worden.
Server angeschalten. Windows Login Screen mit 1 x admin (NEU) 1 x administrator + 1 x Standard-user + 1 x neues Konto
Ablauf: Kundenterin Montag früh. Server war Kundenseitig schon ausgeschalten worden.
Server angeschalten. Windows Login Screen mit 1 x admin (NEU) 1 x administrator + 1 x Standard-user + 1 x neues Konto
Grober Fehler.
Bevor man die Kiste wieder einschaltet, baut man die Festplatten aus und macht ein Image. Alles andere birgt die gefahr, es ncoh schlimmer zu machen. moderne malware erkennt "Recovery-Versuche" und zerstört das ganze unwiederruflich.
Sprich: Lt. Kunde gab es 2 neue Benutzerkonten die es vorher definitiv nicht gab. Das erklärte dann auch das nicht funktionierende Passwort.
Daraufhin erklärte ich dem Kunden, was mit sein System vermutlich passiert ist. Darauf hin wollte er eine anzeige tätigen.
Daraufhin wurde die Kiste wieder runtergefahren und mittels boot-image eine sektor-kopie vorgenommen.
Daraufhin erklärte ich dem Kunden, was mit sein System vermutlich passiert ist. Darauf hin wollte er eine anzeige tätigen.
Daraufhin wurde die Kiste wieder runtergefahren und mittels boot-image eine sektor-kopie vorgenommen.
In diesem Zeitraum hatte das infizierte System mehr Gelegenheit mehr Böses anzustellen.
Egal: Ich starte jetzt zum Kunden und versuche mittels saubere CMD-Datein ein login zu erzwingen. Geht das nicht, scheint auch ne Gruppenrichtlinen oder an der SAM Datei wurde rummanipuliert... demnächst werde ich es wissen
Schau auf jeden Fall, daß die Kiste isoliert ist und vor allem, daß die Imagekopie auch wirklich sauber und komplett ist - und zwar bevor die Kiste wieder eingeschaltet wird!
lks