12
Seltsames Phänomen zerstört Windows-Registry - Virus oder nicht?
Hallo.
Wir momentan ein äußerst seltsames Problem, bei dem ich mir nicht sicher bin ob es sich um einen Virus/Hackerangriff oder einfach einer Fehlkonfiguration oder ähnlichem handelt.
Folgendes:
Am letzten Mittwoch morgen konnten einige PCs von uns nicht mehr in Windows booten und erhielten einen Bluescreen mit STOP 7B (INACCESIBLE BOOT DEVICE). BIOS-Einstellungen, etc. waren alle korrekt (Stichwort AHCI/IDE). Es gab keine sinnvolle Erklärung dafür oder nennenswerte Änderungen, die dieses Problem hätten versurachen können.
Das Problem hat dann nach und nach immer mehr PCs betroffen, die alle im gleichen Netwerk und der gleichen Domäne hängen.
Die User haben alle lokale Adminrechte.
Was ich herausgefunden habe:
- Eine "Infektion" eines PCs findet nicht statt, wenn der User keine lokalen Adminrechte hat
- Was zu dem Bluescreen führt:
Ich habe eine VM erstellt und mich mit einem "normalen" Domänenuser angemeldet und die "Infektion" abgewartet. Dabei habe ich mit ProcessMonitor, WireShark und ProcessExplorer sämtliche Ereignisse beobachtet.
Bei der Machine wird nach der Windows-Anmeldung nach ca. 10-15 Minuten die TrustedInstaller.exe gestartet. Diese macht in der Windows-Registry ein UnloadKey auf "HKLM/COMPONENTS" und "HKLM/SOFTWARE".
Danach läuft die Maschine erstmal weiter. Natürlich haben hier dann schon einige Programme (die ihre Registryeinträge nicht nach jedem Start prüfen und neu erzeugen) Probleme und wenn ich die Maschine neu starte, endet das Laden von Windows in dem genannten Bluescreen
- Eine externe Überprüfung des Festplatteninhaltes eines solche "befallenen" PCs lässt keine Rückschlüsse oder auf irgendeine Art von Verschlüsselung von Dateien oder ähnliches erkennen (Erpressungstrojaner)
- Ich habe diverse Virenscanner (Norman, McAfee Stinger, Kasperky, diverse Live-Boot-CDs mit Multiscannern) sowohl während des Betriebs als auch offline über mehrere "befallene" Rechner und auch nicht befallene Rechner laufen lassen. Es wurde nichts gefunden.
Ich habe auch schon fehlerhafte Windows-Updates (wir haben einen WSUS) oder eine Fehlkonfiguration im Active Directory/GPOs oder ähnliches vermutet, aber mir fällt absolut keine Möglichkeit ein solch ein Verhalten über diese System hervorzurufen.
Ich wäre wirklich sehr dankbar, wenn irgendjemand schonmal von einem ähnlichen Phänomen gehört hat oder weitere Ansatzpunkte hat. Im Internet habe ich leider seit nun zwei Tagen nichts hilfreiches gefunden oder einen Bericht mit einem ähnlichen Problem.
Vielen Dank im Voraus,
HrwSiggi.
Wir momentan ein äußerst seltsames Problem, bei dem ich mir nicht sicher bin ob es sich um einen Virus/Hackerangriff oder einfach einer Fehlkonfiguration oder ähnlichem handelt.
Folgendes:
Am letzten Mittwoch morgen konnten einige PCs von uns nicht mehr in Windows booten und erhielten einen Bluescreen mit STOP 7B (INACCESIBLE BOOT DEVICE). BIOS-Einstellungen, etc. waren alle korrekt (Stichwort AHCI/IDE). Es gab keine sinnvolle Erklärung dafür oder nennenswerte Änderungen, die dieses Problem hätten versurachen können.
Das Problem hat dann nach und nach immer mehr PCs betroffen, die alle im gleichen Netwerk und der gleichen Domäne hängen.
Die User haben alle lokale Adminrechte.
Was ich herausgefunden habe:
- Eine "Infektion" eines PCs findet nicht statt, wenn der User keine lokalen Adminrechte hat
- Was zu dem Bluescreen führt:
Ich habe eine VM erstellt und mich mit einem "normalen" Domänenuser angemeldet und die "Infektion" abgewartet. Dabei habe ich mit ProcessMonitor, WireShark und ProcessExplorer sämtliche Ereignisse beobachtet.
Bei der Machine wird nach der Windows-Anmeldung nach ca. 10-15 Minuten die TrustedInstaller.exe gestartet. Diese macht in der Windows-Registry ein UnloadKey auf "HKLM/COMPONENTS" und "HKLM/SOFTWARE".
Danach läuft die Maschine erstmal weiter. Natürlich haben hier dann schon einige Programme (die ihre Registryeinträge nicht nach jedem Start prüfen und neu erzeugen) Probleme und wenn ich die Maschine neu starte, endet das Laden von Windows in dem genannten Bluescreen
- Eine externe Überprüfung des Festplatteninhaltes eines solche "befallenen" PCs lässt keine Rückschlüsse oder auf irgendeine Art von Verschlüsselung von Dateien oder ähnliches erkennen (Erpressungstrojaner)
- Ich habe diverse Virenscanner (Norman, McAfee Stinger, Kasperky, diverse Live-Boot-CDs mit Multiscannern) sowohl während des Betriebs als auch offline über mehrere "befallene" Rechner und auch nicht befallene Rechner laufen lassen. Es wurde nichts gefunden.
Ich habe auch schon fehlerhafte Windows-Updates (wir haben einen WSUS) oder eine Fehlkonfiguration im Active Directory/GPOs oder ähnliches vermutet, aber mir fällt absolut keine Möglichkeit ein solch ein Verhalten über diese System hervorzurufen.
Ich wäre wirklich sehr dankbar, wenn irgendjemand schonmal von einem ähnlichen Phänomen gehört hat oder weitere Ansatzpunkte hat. Im Internet habe ich leider seit nun zwei Tagen nichts hilfreiches gefunden oder einen Bericht mit einem ähnlichen Problem.
Vielen Dank im Voraus,
HrwSiggi.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 342305
Url: https://administrator.de/contentid/342305
Printed on: April 26, 2024 at 11:04 o'clock
12 Comments
Latest comment
Hi.
Wie soll denn eine "Infektion" stattfinden? Bei einer frischen Maschine sind alle Ports zu, da kann kein Wurm reinhopsen.
beobachte bitte genauer, was da passiert, bevor der Trusted installer loslegt. Teste es mal auf einem Rechner ohne Netzwerkzugang - hier wird nichts passieren, was ein Wunder. Was also kann Deine Testmaschine beeinflussen?
Wie soll denn eine "Infektion" stattfinden? Bei einer frischen Maschine sind alle Ports zu, da kann kein Wurm reinhopsen.
beobachte bitte genauer, was da passiert, bevor der Trusted installer loslegt. Teste es mal auf einem Rechner ohne Netzwerkzugang - hier wird nichts passieren, was ein Wunder. Was also kann Deine Testmaschine beeinflussen?
Hi,,
Wie? Z. B. von einer versauten Installationsquelle.
Rest wegen Mehrfachposting gelöscht. Ein Thread zum gleichen Problem reicht.
Zitat von @DerWoWusste:
Wie soll denn eine "Infektion" stattfinden? Bei einer frischen Maschine sind alle Ports zu, da kann kein Wurm reinhopsen.
Wie soll denn eine "Infektion" stattfinden? Bei einer frischen Maschine sind alle Ports zu, da kann kein Wurm reinhopsen.
Wie? Z. B. von einer versauten Installationsquelle.
Rest wegen Mehrfachposting gelöscht. Ein Thread zum gleichen Problem reicht.
Hallo,
Welches Windows?
Wer benutzt den TrustedInstaller um die Registry zu entladen? Das musst Du heraus finden.
Der PC der als letztes noch laeuft, der User war es.
BFF
Welches Windows?
Wer benutzt den TrustedInstaller um die Registry zu entladen? Das musst Du heraus finden.
Die User haben alle lokale Adminrechte.
Der PC der als letztes noch laeuft, der User war es.
BFF
Was passiert denn mit Maschinen, die nicht Teil der Domäne sind?
Werden die ebenfalls "befallen" oder passiert denen nichts?
Dann könnte man zumindest mal WSUS oder irgendwelche per GPO verteilten Scripte ausschließen.
Werden die ebenfalls "befallen" oder passiert denen nichts?
Dann könnte man zumindest mal WSUS oder irgendwelche per GPO verteilten Scripte ausschließen.
@DerWoWusste
Die Testmaschine befand sich natürlich in der Domäne und es handelte sich bei dem Testuser um einen Account mit "Mitarbeiter-Rechten".
Ich habe das ganze ja wie schon wie gesagt beobachtet.
- Wireshark: Es werden zwischendurch Standardanfragen an den WSUS und an den DC gesendet und empfangen (nichts ungewöhnliches)
- ProcessMonitor: ohne besondere vorherige Vorkommnisse startet plötzlich der TrustedInstaller und beginnt eben mit dem "Löschen" bzw. dem Unload der genannten Registry-Hives. Danach tut sich nichts mehr und die Maschine läuft bis zum Neustart eigentlich normal weiter. Interessant ist auch, dass er die ganzen Registry-Schlüssel vorher ausliest. Das heißt er beginnt nicht mit einem stumpfen Löschen, sondern schaut vorher nach was da ist bzw. was er da löscht. Eigentlich auch ein Indiz für mich, dass es kein Virus oder ähnliches ist. Denn warum sollte man das tun?
- ProcessExplorer: bei der gestarteten TrustedInstaller-Instanz handelt es sich augenscheinlich um den ganz normalen TrustedInstaller von Windows (also kein getarnter Prozess mit gleichem Namen oder ähnliches)
Wichtig zu erwähnen ist vielleicht noch, dass dieses Phänomen auch abläuft, wenn der User keine lokalen Administratorrechte hat. ABER hat er dann einfach keine Rechte das UnloadKey auszuführen. Das Auslesen der Einträge und der Versuch des "Löschens" findet aber dennoch statt!
@114685
Siehe meine Erklärung im anderen Thread.
Aber danke für die Aufsichtstätigkeit.
@BassFishFox
Das Problem tritt sowohl bei Windows 7- als auch Windows 10-Rechnern auf.
Wie ich schon sagte handelt es sich um den normalen TrustedInstaller-Prozess von Windows, der auch gestartet wird, wenn du ein MSI-Paket oder Updates installierst.
Ich konnte bis jetzt nicht herausfinden bzw. kenne keine Möglichkeit zu sehen welcher Prozess oder was genau den TrustedInstaller startet.
@LordGurke
Das habe ich tatsächlich so noch nicht testen können. Werde ich nachholen. Bisher waren alle Rechner an der Domäne registriert.
Ich habe jedoch schon den WSUS komplett heruntergefahren und auch Testuser erstellt, die keine GPOs bekommen. Dennoch trat dort auch das Problem auf.
Die Testmaschine befand sich natürlich in der Domäne und es handelte sich bei dem Testuser um einen Account mit "Mitarbeiter-Rechten".
Ich habe das ganze ja wie schon wie gesagt beobachtet.
- Wireshark: Es werden zwischendurch Standardanfragen an den WSUS und an den DC gesendet und empfangen (nichts ungewöhnliches)
- ProcessMonitor: ohne besondere vorherige Vorkommnisse startet plötzlich der TrustedInstaller und beginnt eben mit dem "Löschen" bzw. dem Unload der genannten Registry-Hives. Danach tut sich nichts mehr und die Maschine läuft bis zum Neustart eigentlich normal weiter. Interessant ist auch, dass er die ganzen Registry-Schlüssel vorher ausliest. Das heißt er beginnt nicht mit einem stumpfen Löschen, sondern schaut vorher nach was da ist bzw. was er da löscht. Eigentlich auch ein Indiz für mich, dass es kein Virus oder ähnliches ist. Denn warum sollte man das tun?
- ProcessExplorer: bei der gestarteten TrustedInstaller-Instanz handelt es sich augenscheinlich um den ganz normalen TrustedInstaller von Windows (also kein getarnter Prozess mit gleichem Namen oder ähnliches)
Wichtig zu erwähnen ist vielleicht noch, dass dieses Phänomen auch abläuft, wenn der User keine lokalen Administratorrechte hat. ABER hat er dann einfach keine Rechte das UnloadKey auszuführen. Das Auslesen der Einträge und der Versuch des "Löschens" findet aber dennoch statt!
@114685
Siehe meine Erklärung im anderen Thread.
Aber danke für die Aufsichtstätigkeit.
@BassFishFox
Das Problem tritt sowohl bei Windows 7- als auch Windows 10-Rechnern auf.
Wie ich schon sagte handelt es sich um den normalen TrustedInstaller-Prozess von Windows, der auch gestartet wird, wenn du ein MSI-Paket oder Updates installierst.
Ich konnte bis jetzt nicht herausfinden bzw. kenne keine Möglichkeit zu sehen welcher Prozess oder was genau den TrustedInstaller startet.
@LordGurke
Das habe ich tatsächlich so noch nicht testen können. Werde ich nachholen. Bisher waren alle Rechner an der Domäne registriert.
Ich habe jedoch schon den WSUS komplett heruntergefahren und auch Testuser erstellt, die keine GPOs bekommen. Dennoch trat dort auch das Problem auf.
Wichtig zu erwähnen ist vielleicht noch, dass dieses Phänomen auch abläuft, wenn der User keine lokalen Administratorrechte hat. ABER hat er dann einfach keine Rechte das UnloadKey auszuführen. Das Auslesen der Einträge und der Versuch des "Löschens" findet aber dennoch statt!
Deine Beobachtungsgabe in allen Ehren, aber wie die Nutzerrechte hier überhaupt reinspielen sollten, wo doch das Reg unload gar nicht mit den Nutzerrechten passiert, das ist unklar. Ich kann mir nicht vorstellen, dass Du das richtig beobachtest. Wenn man davon ausgeht, dass der Einfluss von außen kommt, dann spielt der angemeldete Nutzer keine Rolle. Um von außen mit einem Rechner zu kommunizieren, musst Du Adminrechte haben - da brauchst Du den Nutzer nicht - oder mit einem Dienst kommunizieren, den Du anweist, etwas zu tun - da brauchst Du den angemeldeten Nutzer auch nicht.Bin gespannt, was Du noch rausfindest.
Es handelte sich um eine GPO mit Abmeldeskript (.bat), welches ein anderer Administrator angelegt hatte.
Es sollten damit Cache-Dateien gelöscht werden.
Das Problem war jedoch, dass er sich auf das AppData-Verzeichnis eines Programmes gestellt hat (cd) und anschließend ein del *.* ausführt.
Sofern der Pfad existiert ist das auch ok, tut er das aber nicht steht die Shell im Standardverzeichnis.
Und der Pfad war eben bei den wenigsten Usern vorhanden.
Führt ein angemeldeter User die Shell aus ist dieser Standardpfad das User-Profil. Bei einem Abmeldeskript über GPO wird das aber nicht vom User ausgeführt und somit steht die Shell in C:\ .
Und ein del *.* auf C:\ mit lokalen Administratorrechten ist nicht ganz so lustig.
Meine Beobachtung des TrustedInstaller-Prozesses, etc. war dementsprechend wohl einfach nur eine Folge dieser Sache (Aufräumroutine von Windows).
Es sollten damit Cache-Dateien gelöscht werden.
Das Problem war jedoch, dass er sich auf das AppData-Verzeichnis eines Programmes gestellt hat (cd) und anschließend ein del *.* ausführt.
Sofern der Pfad existiert ist das auch ok, tut er das aber nicht steht die Shell im Standardverzeichnis.
Und der Pfad war eben bei den wenigsten Usern vorhanden.
Führt ein angemeldeter User die Shell aus ist dieser Standardpfad das User-Profil. Bei einem Abmeldeskript über GPO wird das aber nicht vom User ausgeführt und somit steht die Shell in C:\ .
Und ein del *.* auf C:\ mit lokalen Administratorrechten ist nicht ganz so lustig.
Meine Beobachtung des TrustedInstaller-Prozesses, etc. war dementsprechend wohl einfach nur eine Folge dieser Sache (Aufräumroutine von Windows).
Und ein del *.* auf C:\ mit lokalen Administratorrechten ist nicht ganz so lustig
Besonders, wenn die UAC abgeschaltet ist - ein weiterer Grund, dies nicht zu tun. Mit UAC an, wird da fast gar nichts vom System zu löschen sein.
Hi,
Bei mir wird mit *.* gar nichts ohne explizite Bestätigung (Y/N/A)gelöscht, wenn der Parameter /Q nicht angegeben ist, egal ob mit oder ohne UAC. Ist das bei dir anders?
Gruß
Zitat von @DerWoWusste:
Besonders, wenn die UAC abgeschaltet ist - ein weiterer Grund, dies nicht zu tun. Mit UAC an, wird da fast gar nichts vom System zu löschen sein.
Besonders, wenn die UAC abgeschaltet ist - ein weiterer Grund, dies nicht zu tun. Mit UAC an, wird da fast gar nichts vom System zu löschen sein.
Bei mir wird mit *.* gar nichts ohne explizite Bestätigung (Y/N/A)gelöscht, wenn der Parameter /Q nicht angegeben ist, egal ob mit oder ohne UAC. Ist das bei dir anders?
Gruß
Zitat von @114685:
Hi,
Bei mir wird mit *.* gar nichts ohne explizite Bestätigung (Y/N/A)gelöscht, egal ob mit oder ohne UAC. Ist das bei dir anders?
Gruß
Hi,
Zitat von @DerWoWusste:
Besonders, wenn die UAC abgeschaltet ist - ein weiterer Grund, dies nicht zu tun. Mit UAC an, wird da fast gar nichts vom System zu löschen sein.
Besonders, wenn die UAC abgeschaltet ist - ein weiterer Grund, dies nicht zu tun. Mit UAC an, wird da fast gar nichts vom System zu löschen sein.
Bei mir wird mit *.* gar nichts ohne explizite Bestätigung (Y/N/A)gelöscht, egal ob mit oder ohne UAC. Ist das bei dir anders?
Gruß
/q /s
Ist das nun wichtig zu diskutieren? 
Für mich ja, wenn ich wissen möchte, ob sich in einer Domänenumgebung etwas ändert. Das ist keine Diskussion, sondern eine Frage. Ein Ja bzw. Nein hätte mir gereicht.