Unter Windows kehren entfernte Programme oder Einstellungen nach jedem Neustart zurück: Wie finde ich den Persistenzmechanismus?

Wenn unter Windows scheinbar entfernte Programme nach jedem Neustart wieder auftauchen oder Konfigurationen zurückgesetzt werden, steckt dahinter fast nie „Magie“, sondern ein Persistenzmechanismus: ein definierter Pfad oder Dienst, der beim Start, bei Benutzeranmeldung oder zu bestimmten Ereignissen erneut Komponenten nachlädt oder Einstellungen durchsetzt. In Unternehmensumgebungen sind solche Effekte häufig beabsichtigt, etwa durch Gruppenrichtlinien, MDM-Vorgaben oder Softwareverteilung.

Auf privaten Systemen sind es oft Updater, Hintergrunddienste oder Autostart-Einträge, die eine Deinstallation unvollständig lassen oder Einstellungen wiederherstellen. Gleichzeitig kann das Verhalten ein Indikator für PUPs, Manipulationen am Browser-Profil oder kompromittierte Systeme sein, etwa durch WMI-Persistenz, geplante Aufgaben oder missbräuchlich installierte Zertifikate. Für Betroffene ist vor allem eine Frage entscheidend: Welcher konkrete Mechanismus sorgt dafür, dass nach jedem Neustart wieder derselbe Zustand hergestellt wird, und wie lässt sich das nachvollziehbar und forensisch sauber feststellen, ohne legitime Verwaltungsmechanismen zu beschädigen oder eine mögliche Sicherheitslage zu übersehen?

Technische Ursachen: Legitimer Autostart, Richtliniendurchsetzung, Updater und unerwünschte Persistenz sauber abgrenzen

Wenn entfernte Programme, Browser-Erweiterungen oder System- und App-Einstellungen nach jedem Neustart wieder auftauchen, liegt fast immer ein Persistenzmechanismus vor, der die gewünschte Änderung rückgängig macht oder die Software erneut installiert. Technisch ist das kein einzelnes „Windows-Problem“, sondern das Resultat einer Komponente, die (1) beim Systemstart oder bei Benutzeranmeldung automatisch ausgeführt wird, (2) Konfigurationen regelmäßig erzwingt oder (3) im Hintergrund als Update- oder Reparaturdienst agiert. Entscheidend ist die saubere Abgrenzung zwischen legitimen Mechanismen (z. B. verwaltete Unternehmensgeräte), unerwünschten, aber meist nicht eindeutig schädlichen Zusatzprogrammen (PUPs) und echter schädlicher Persistenz.

Legitimer Autostart: „Kommt zurück“ ist oft beabsichtigt

Viele Anwendungen bestehen aus mehreren Komponenten (Hauptprogramm, Hintergrunddienst, Updater, Telemetrie/Agent, Browser-Helper). Wird nur der sichtbare Teil deinstalliert, bleibt ein Updater oder Dienst zurück, der bei der nächsten Gelegenheit das Paket wiederherstellt. Ebenso können moderne Apps und Treiberpakete Reparatur-/Wiederherstellungsfunktionen haben, oder sie werden durch einen Hersteller-Agenten (z. B. Drucker-, Audio-, VPN- oder Cloud-Clients) automatisch nachgeladen. Typisch für legitimen Autostart ist ein klarer Herstellerbezug, eine gültige digitale Signatur, ein nachvollziehbarer Installationspfad unter C:\Program Files\ oder C:\Windows\ sowie konsistente Ereignisse in den Windows-Protokollen.

Zu den klassischen Autostart-Orten zählen Einträge für alle Benutzer oder pro Benutzer, geplante Aufgaben und Autostart-Ordner. In vielen Fällen reicht es nicht, „das Programm“ zu löschen; der auslösende Autostart-Eintrag muss identifiziert und entfernt oder korrekt konfiguriert werden (z. B. Updater deaktivieren, Reparaturfunktion abstellen, verwaltete Installation anpassen).

Richtliniendurchsetzung: Wenn Einstellungen nach Neustart gezielt zurückgesetzt werden

In verwalteten Umgebungen (Domäne, Entra ID/Azure AD, MDM/Intune) werden Einstellungen absichtlich durch Richtlinien erzwungen. Das wirkt wie „magisches Wiederkommen“: Ein lokaler Administrator ändert einen Wert, nach Neustart oder nach einer Richtlinienaktualisierung ist der alte Zustand wieder da. Das betrifft besonders Browser-Policies, Windows-Sicherheitsrichtlinien, Defender-Konfigurationen, Proxy/PKI, aber auch App-Bereitstellungen (z. B. „Required“-Apps), die nach Deinstallation automatisch erneut installiert werden.

Wichtig ist die Unterscheidung zwischen lokaler Richtlinie und zentraler Richtlinie: Lokale Änderungen verlieren gegen zentrale Vorgaben. Hinweise sind Einträge unter „Managed by your organization“, Richtlinien-Pfade unter HKLM\SOFTWARE\Policies\ bzw. HKCU\SOFTWARE\Policies\ und ein regelmäßiger Zeitstempelwechsel nach gpupdate oder nach dem Start des Geräts.

Updater, Installer-Stub und „Self-Healing“: Wiederherstellung statt Neuinfektion

Viele Hersteller betreiben separate Update-Mechanismen, die unabhängig von der Hauptanwendung laufen. Entfernt man nur die App, bleibt der Updater bestehen und installiert die App erneut (oder „repariert“ sie). Typisch sind geplante Aufgaben („UpdateTask“, „Maintenance“) oder Dienste („Update Service“). Auch MSI-basierte Installationen können über Reparaturzustände verfügen, und Paketmanager/Unternehmens-Softwareverteilung kann eine gewünschte Soll-Konfiguration („desired state“) regelmäßig durchsetzen.

Unerwünschte Persistenz (PUP/Adware) vs. kompromittierte Persistenz (Malware)

Unerwünschte Programme (PUPs) nutzen oft dieselben Windows-Mechanismen wie legitime Software: Run-Keys, Aufgabenplanung, Browser-Policies oder Dienst-Registrierungen. Der Unterschied liegt weniger im „Wie“ als im Kontext: fehlende oder fragwürdige Signaturen, irreführende Produktnamen, Installationsorte in Benutzerprofilen (%AppData%, %LocalAppData%) und aggressive Wiederherstellung nach Entfernen. Kompromittierte Persistenz geht typischerweise weiter: Tarnnamen, ungewöhnliche Pfade, manipulative Policies, WMI-Event-Subscriptions oder Missbrauch von Systemdiensten/COM-Objekten. In solchen Fällen ist besondere Sorgfalt erforderlich, weil das „Zurückkommen“ Teil einer Abwehr gegen Bereinigung sein kann.

Die folgenden Indikatoren helfen bei der Abgrenzung, ohne bereits in die eigentliche forensische Nachweisführung abzurutschen:

• Hersteller- und Signaturplausibilität: Datei-Eigenschaften und Signatur wirken konsistent; bei Bedarf prüfen mit Get-AuthenticodeSignature "C:\Pfad\zur\Datei.exe".
• Installationspfad und Schreibrechte: Persistenz aus %AppData%, %Temp% oder zufällig benannten Ordnern ist verdächtiger als C:\Program Files\ (Ausnahmen existieren, etwa Updater im Benutzerkontext).
• Richtlinienartefakte: Erzwungene Einstellungen unter HKLM\SOFTWARE\Policies\ oder HKCU\SOFTWARE\Policies\ deuten auf Verwaltung oder Missbrauch; Browser-spezifisch u. a. HKLM\SOFTWARE\Policies\Google\Chrome bzw. HKLM\SOFTWARE\Policies\Microsoft\Edge.
• Aufgabenplanung als „Re-Installer“: Wiederkehrende Tasks mit Trigger „At startup“/„At log on“ oder kurzer Wiederholrate; prüfen mit schtasks /query /fo LIST /v.
• Dienst-/Treiberpersistenz: Unerwartete Dienste oder Treiber, die früh starten; Überblick mit Get-Service | Sort-Object Status,Name und Treiberliste mit sc query type= driver.
• Netzwerk-/Proxy-/Zertifikatsänderungen: Persistente Proxyvorgaben oder neue Root-Zertifikate (z. B. für TLS-Inspection) müssen erklärt werden; Rootstore prüfen u. a. mit certutil -store -user Root und certutil -store Root.

Praktische Abgrenzung: Welche Ursache ist zuerst wahrscheinlich?

Für eine schnelle, technisch belastbare Einordnung zählt vor allem die Kausalität: Kommt etwas exakt nach jedem Neustart (oder jeder Anmeldung) zurück, ist ein Start-/Logon-Trigger wahrscheinlicher als ein periodischer Updater. Passiert es nach 30–120 Minuten oder zu festen Uhrzeiten, spricht das eher für geplante Aufgaben, Update-Agents oder MDM-Sync-Intervalle. Kommt es unmittelbar nach einem manuellen „gpupdate“ wieder, ist Richtliniendurchsetzung die erste Hypothese. Und wenn zusätzlich Security-relevante Spuren auftreten (ungewollte Root-Zertifikate, deaktivierte Schutzfunktionen, unbekannte Treiber), muss die Möglichkeit einer Kompromittierung priorisiert werden, selbst wenn der sichtbare Effekt „nur“ eine zurückgesetzte Einstellung ist.

Die weitere Analyse sollte dann konsequent an der wahrscheinlichsten Klasse ansetzen: Autostart/Tasks/Dienste für Neustart-Korrelation, Policies/MDM für erzwungene Konfigurationen, Updater/Agenten für Wiederinstallation. Erst wenn diese legitimen Erklärungen nicht passen oder Artefakte unplausibel bleiben, ist eine Eskalation in Richtung Incident-Response angemessen.

Methodische Diagnose und Entscheidung: Korrelation mit Neustarts, Eventlogs und Werkzeuge (Task Scheduler, Autoruns, Services, gpresult) bis zur Frage „Bereinigen oder neu aufsetzen?“

Wenn entfernte Programme, Browser-Erweiterungen oder Systemeinstellungen nach jedem Neustart wieder auftauchen, ist der entscheidende Schritt die saubere Korrelation: Was passiert genau beim Booten, bei der Anmeldung oder zeitverzögert im Hintergrund? Eine belastbare Diagnose entsteht, wenn Beobachtung (Zeitpunkt und Trigger), Artefakte (Logs und Konfiguration) und Werkzeuge (Task Scheduler, Autoruns, Dienste, Richtlinienauswertung) zusammengeführt werden. Dadurch lässt sich nicht nur der verantwortliche Persistenzmechanismus identifizieren, sondern auch eine Entscheidung ableiten, ob eine manuelle Bereinigung vertretbar ist oder ein Neuaufsetzen wirtschaftlicher und sicherer.

1) Reproduzierbarkeit und zeitliche Korrelation: Boot vs. Logon vs. „später“

Vor jeder Werkzeugnutzung sollte das Verhalten in wenigen, klaren Versuchen reproduzierbar gemacht werden: Tritt die Rückkehr unmittelbar nach dem Startbildschirm auf (typisch für Dienste/Treiber), erst nach der Benutzeranmeldung (typisch für Run-Keys/Autostartordner), oder erst Minuten später (häufig geplante Aufgaben, Updater, WMI-Trigger, Management-Agenten)? Diese Einordnung reduziert die Suchfläche deutlich.

• Beobachtungsprotokoll anlegen: Zeitpunkt notieren, wann das Programm/Setting wieder erscheint (z. B. „30 Sekunden nach Logon“), und ob es bei Neustart und bei Herunterfahren → Kaltstart identisch ist.
• Sauberer Neustart zum Abgrenzen: Testweise einmal „abgesicherter Modus“ oder „Clean Boot“ (nur Microsoft-Dienste) nutzen, um Drittanbieter-Autostarts auszuschließen; für Clean Boot sind relevant msconfig (Dienste) und der Task-Manager-Reiter „Autostart“.
• Trigger klären: Prüfen, ob die Änderung durch Benutzeraktion rückgängig gemacht wird (z. B. nach erneutem Browserstart) oder ausschließlich durch Systemereignisse (Boot/Logon/Netzwerk verfügbar).

2) Eventlogs gezielt nutzen: Hinweise statt Volltextsuche

Windows protokolliert viele Persistenz- und Ausführungsereignisse, jedoch verteilt über mehrere Logs. Ziel ist nicht „alles zu lesen“, sondern Spuren rund um den Zeitpunkt der Rückkehr zu finden: Start eines Dienstes, Ausführung einer geplanten Aufgabe, Installations- oder Reparaturvorgänge (MSI), Policy-Aktualisierungen oder Sicherheitsprodukte, die bewusst Komponenten wiederherstellen.

• Neustartfenster markieren: Die Systemstartzeit auswerten, z. B. in der Ereignisanzeige unter Windows-Protokolle\System; zusätzlich liefert wevtutil qe System /q:"*[System[(EventID=6005 or EventID=6006 or EventID=6008)]]" /f:text /c:20 oft eine schnelle Orientierung.
• Aufgabenplanung-Events prüfen: In Anwendungs- und Dienstprotokolle\Microsoft\Windows\TaskScheduler\Operational nach Ausführungen rund um das Zeitfenster suchen; bei Bedarf aktivieren und anschließend mit wevtutil qe Microsoft-Windows-TaskScheduler/Operational /f:text /c:50 abfragen.
• Installations-/Reparaturspuren: In Windows-Protokolle\Application nach MsiInstaller-Einträgen im Zeitfenster suchen; wiederkehrende „Repair“-Vorgänge sind ein starkes Indiz für Selbstheilungsmechanismen oder Updater.
• Policy-Aktualisierung korrelieren: Gruppenrichtlinienereignisse finden sich typischerweise unter Anwendungs- und Dienstprotokolle\Microsoft\Windows\GroupPolicy\Operational; relevant, wenn Einstellungen (z. B. Browser-Policies, Sicherheitsoptionen) nach Logon erneut gesetzt werden.

3) Task Scheduler systematisch prüfen: Trigger, Aktionen, Ausführungskontext

Geplante Aufgaben sind einer der häufigsten Gründe für „kommt nach Neustart zurück“, weil sie nicht nur beim Logon, sondern auch zeit- oder ereignisbasiert starten können. Entscheidend ist die Kombination aus Trigger (Wann?), Aktion (Was startet?) und Sicherheitsoptionen (Als welcher Benutzer? Mit höchsten Privilegien?). In Umgebungen mit Management-Software sind Aufgaben oft der Mechanismus, über den Agenten Komponenten nachinstallieren oder Konfigurationen erzwingen.

• Alle Aufgaben mit Details exportieren: schtasks /query /fo LIST /v > "%TEMP%\tasks.txt" und im Ergebnis nach auffälligen Pfaden, Parametern oder Herstellern suchen.
• Startpunkte auf Neustart/Logon prüfen: In der GUI (Aufgabenplanung) insbesondere „Trigger“ (z. B. „Beim Start des Computers“, „Bei Anmeldung“, „Bei Ereignis“) und „Aktionen“ (Aufruf von powershell.exe, wscript.exe, cmd.exe oder ungewöhnlichen Pfaden unter %ProgramData%, %AppData%, %TEMP%) kontrollieren.
• Ausführungskonto bewerten: Aufgaben, die unter SYSTEM laufen oder „Mit höchsten Privilegien“ gesetzt haben, verdienen Priorität; sie können auch nach einer Deinstallation Reste nachziehen oder Einstellungen systemweit zurücksetzen.

4) Autoruns als Querschnittswerkzeug: schnelle Abdeckung vieler Persistenzpfade

Autoruns (Sysinternals) eignet sich als „Querschnittsscanner“, weil es Autostart-Mechanismen aus Registry, Dateisystem, Tasks, Services, Treibern, Explorer-/Browser-Integrationen und mehr konsolidiert. Für belastbare Ergebnisse sollten Microsoft-Einträge ausgeblendet und Signaturen geprüft werden; dadurch treten Drittanbieter- und Anomalie-Einträge stärker hervor. Wichtig ist, nicht blind zu „deaktivieren“, sondern erst den Zusammenhang mit dem beobachteten Symptom zu belegen.

• Basiseinstellungen für Analyse: In Autoruns „Hide Microsoft Entries“ aktivieren und „Verify Code Signatures“ nutzen; verdächtige Einträge sind häufig unsigniert, aus ungewöhnlichen Verzeichnissen oder mit obfuskierten Parametern.
• Relevante Reiter priorisieren: Logon (Run/RunOnce, Autostartordner), Scheduled Tasks, Services, Drivers, WMI, Explorer (Shell Extensions) und bei Browserproblemen Internet Explorer/Edge-bezogene Bereiche (je nach Autoruns-Version).
• Beweisführung vor Eingriff: Pfad und Hash/Signatur notieren, Parent-Produkt identifizieren (Publisher, Installationsverzeichnis), anschließend gezielt im Eventlog-Zeitfenster prüfen, ob genau dieser Eintrag zur beobachteten Uhrzeit ausgeführt wurde.

5) Dienste und Treiber: Persistenz mit hoher Wirkung (und höherem Risiko)

Dienste und Treiber erklären häufig Fälle, in denen sich Einstellungen schon vor der Anmeldung zurückstellen oder Komponenten unmittelbar nach dem Booten wieder erscheinen. Gleichzeitig steigt hier das Risiko: Fehlgriffe können das System unbootbar machen. Daher sollte zuerst identifiziert werden, ob ein legitimes Produkt (z. B. Security/Management/Backup/VPN) dahintersteht oder ein Fremdeintrag mit unklarem Ursprung.

• Dienste inventarisieren: Get-CimInstance Win32_Service | Select-Object Name,StartMode,State,StartName,PathName | Sort-Object StartMode,Name und auf ungewöhnliche PathName-Werte (z. B. aus Benutzerprofilen) sowie Konten wie LocalSystem achten.
• Treiberstarts prüfen: sc query type= driver sowie im Geräte-Manager „Ausgeblendete Geräte anzeigen“; auffällige Kernel-Treiber ohne klaren Hersteller sind ein starkes Warnsignal.
• Änderungen nachvollziehen: Bei Verdacht zunächst nur deaktivieren statt löschen (z. B. Starttyp), und nach einem Neustart verifizieren, ob das Symptom ausbleibt; danach die Ursache (Installer, Updater, Policy) suchen, die den Dienst wieder aktiviert.

6) Richtlinien sicher beurteilen: gpresult, RSOP und Browser-Policies

Wenn Einstellungen „wie von selbst“ zurückkehren, steckt häufig eine Richtlinie dahinter: Domänen-GPO, lokale Richtlinie, MDM/Intune-Richtlinie oder eine Anwendung, die Policies als Steuermechanismus nutzt (insbesondere Browser). Der diagnostische Unterschied zu Malware: Richtlinienänderungen sind oft konsistent, wiederholbar und mit einer klaren Quelle (GPO-Name, MDM) belegbar.

• GPO-Auswertung erstellen: gpresult /h "%TEMP%\gpresult.html" (als Administrator) und in der HTML-Ausgabe „Gewonnene Richtlinienobjekte“ sowie „Administrative Vorlagen“ prüfen.
• Lokale vs. Domänenwirkung trennen: Mit rsop.msc (Resultant Set of Policy) die effektiven Einstellungen anzeigen; bei gemanagten Geräten zusätzlich MDM-Richtlinien in den Windows-Einstellungen („Zugriff auf Arbeits- oder Schulkonto“) berücksichtigen.
• Browser-Policies gezielt abklären: Bei erzwungenen Startseiten/Erweiterungen/Proxy-Einstellungen sind häufig Policies unter HKLM\Software\Policies\Microsoft\Edge bzw. HKLM\Software\Policies\Google\Chrome relevant; vor Änderungen immer die Quelle (GPO/MDM/Sicherheitsprodukt) verifizieren.

7) Entscheidungspfad: legitime Wiederherstellung, PUP oder Kompromittierung?

Nachdem der Mechanismus identifiziert ist, folgt die Einordnung. Ein Updater oder Management-Agent kann entfernte Komponenten „korrekt“ wiederherstellen, ebenso Sicherheitssoftware (z. B. durch Selbstschutz/Tamper-Protection-Mechanismen, je nach Produkt). PUPs (Potentially Unwanted Programs) fallen oft durch aggressive Browser- oder Suchanbieter-Änderungen auf und hängen an Tasks/Run-Keys. Eine Kompromittierung ist wahrscheinlicher, wenn Privilegien missbraucht werden (SYSTEM-Kontext), ungewöhnliche Speicherorte genutzt werden oder mehrere Persistenzpfade parallel existieren.

8) „Bereinigen oder neu aufsetzen?“: Kriterien für eine belastbare Entscheidung

Manuelle Bereinigung ist sinnvoll, wenn der Auslöser eindeutig ist, sich mit wenigen, nachvollziehbaren Maßnahmen entfernen lässt und keine Anzeichen für tiefgreifende Manipulation bestehen. Ein Neuaufsetzen ist oft die bessere Option, wenn die Herkunft unklar bleibt, Systemkomponenten betroffen sind oder der Aufwand zur verlässlichen Bereinigung den Wert der Arbeitszeit übersteigt. Maßgeblich sind nicht nur Sicherheit, sondern auch Wiederholbarkeit, Dokumentierbarkeit und das Risiko versteckter Persistenz.

• Für Bereinigung spricht: Verantwortlicher Eintrag ist eindeutig (z. B. einzelne geplante Aufgabe), Signatur/Hersteller ist plausibel, und nach Entfernen sowie Neustart bleibt der Zustand stabil; begleitend sollte eine vollständige Überprüfung durch aktuelle Sicherheitssoftware erfolgen.
• Für Neuaufsetzen spricht: Unklare Quelle trotz Analyse, Persistenz mit hohen Rechten (Dienste/Treiber), Hinweise auf Credential-Theft oder seitliche Bewegungen, oder wiederholte Re-Infektion nach vermeintlicher Bereinigung; zusätzlich, wenn Richtlinien/Management unbekannt sind und zentrale Kontrolle nicht geklärt werden kann.
• Datensicherung mit Risikoabwägung: Bei Verdacht auf Kompromittierung nur notwendige Nutzdaten sichern (Dokumente), keine ausführbaren Dateien übernehmen; Pfade mit hohem Risiko sind u. a. %AppData%, %LocalAppData%, %ProgramData% und Autostart-Verzeichnisse, die vor Rücksicherung gesondert geprüft werden sollten.
• Wirtschaftlichkeit dokumentieren: Aufwandsschätzung (Analyse, Bereinigung, Validierung, Monitoring) gegen standardisiertes Neuaufsetzen (Imaging/Autopilot, Baseline, Wiederherstellung der Daten) stellen; die Entscheidung sollte nachvollziehbar begründet und revisionsfest protokolliert werden.