Wenn gpupdate zur Waffe wird

In vielen Häusern arbeiten Red Team und Incident Response nebeneinander her statt miteinander. Der folgende Fall zeigt, was möglich ist, wenn beide Seiten dasselbe Artefakt in die Hand nehmen.

Bei einem IR-Einsatz erhielten wir ein Malware-Sample, mit dem sich ein Angreifer auf dem System unseres Kunden lokale Administratorrechte verschafft hatte. Der Fingerabdruck passte zu CVE-2026-21533, einer Local Privilege Escalation im Windows-Remote-Desktop-Dienst oder zumindest zu einer nah verwandten Variante dieser Schwachstelle.

Wir haben das Sample im Detail analysiert und per Reverse Engineering so weit rekonstruiert, bis ein lauffähiger Proof of Concept vorlag. Für unser IR-Team ergab das ein sehr präzises Bild davon, an welcher Stelle der Angriff die Rechte ausweitete und für unser Red Team ein hilfreiches Werkzeug für kommende Engagements.

Die meisten Angreiferwerkzeuge, die wir in Incidents zu sehen bekommen, sind bekannte Größen. Remote-Access-Tools wie TeamViewer oder AnyDesk etwa, mit denen sich Angreifer einen bequemen, unauffälligen Zugang zu ihren Opfern offenhalten. Standardrepertoire, das man schnell einordnet.

In diesem Fall lag uns etwas anderes vor. Am Anfang stand der Exploit einer Schwachstelle, zu der es zum Zeitpunkt unserer Analyse öffentlich kaum belastbare Informationen gab. Eine Lücke im Windows-Remote-Desktop-Dienst, über die ein Angreifer mit lokalem Zugriff seine Rechte in den Kontext eines lokalen Administrators ausweiten kann (CVE-2026-21533).

Microsoft hatte die Lücke im Februar 2026 geschlossen, nachdem CrowdStrike ihre aktive Ausnutzung gemeldet hatte. Auf dem betroffenen System unseres Kunden fehlte genau dieses Update. Nach dem Erstzugriff konnte sich der Angreifer damit lokale Administratorrechte verschaffen. Und von dort verlief der Rest nach bekanntem Muster: Zugangsdaten aus System und Arbeitsspeicher abgreifen und sich seitlich weiter durchs Netz bewegen.

Ausgenutzt wurde die Lücke über zwei Dateien, die wir im Zuge unserer forensischen Maßnahmen als Artefakte sichern konnten: de.exe und eng.exe. Beide ließen sich extrahieren und in Ruhe per Reverse Engineering zerlegen.

Verteilt wurde die Malware über ein kompromittiertes OneDrive-Konto, in Form eines passwortgeschützten Archivs. Zum Zeitpunkt unserer Analyse lag es dort noch, sodass wir uns Zugriff verschaffen und den Inhalt sichern konnten.

Dass ein solches Archiv verschlüsselt ist, ist kein Zufall, sondern Standard. Ein passwortgeschütztes Archiv ist für eine automatisierte Inhaltsprüfung während des Downloads eine Blackbox. Gateway-Scanner, Proxy-Inspektion und der signaturbasierte Virenscanner am Endpunkt kommen an den Inhalt nicht heran, solange ihnen das Passwort fehlt.

Statt der eigentlichen Schadsoftware sehen sie nur ein undurchsichtiges Containerformat und damit nichts, woran eine Signatur greifen könnte. Das Passwort steht dabei fast immer im Klartext daneben, in der Phishing-Mail oder auf der Landing Page, denn der legitime Empfänger soll das Archiv ja öffnen.

Im vorliegenden Fall bestand dieses Passwort aus den vier Ziffern 1123. Aus Sicht der Kryptografie ist das nichts: vier Zeichen aus einem Alphabet von zehn ergeben einen Suchraum von zehntausend Möglichkeiten. Wir haben den Passwort-Hash aus dem Archiv extrahiert und ihn „John the Ripper“ übergeben, das den Vier-Ziffern-Raum in Sekundenbruchteilen durchläuft. Entsprechend schnell hatten wir das Passwort und damit die Malware im Klartext.

Man könnte den Angreifer für diese Nachlässigkeit belächeln, aber das ginge am Zweck vorbei. Für sein Ziel ist die Stärke des Passworts nahezu belanglos. Die Verschlüsselung soll keinen gezielten Cracking-Versuch überstehen, sie soll lediglich die automatisierte Prüfung auf dem Weg zum Opfer aushebeln. Das leistet ein Archiv mit dem Passwort 1123 genauso zuverlässig wie eines mit einer 30-stelligen Passphrase. Für uns als Analysten war der schwache Schutz ein willkommener Zeitgewinn. Für die Schutzwirkung des Angreifers spielte er keine Rolle.

Die de.exe haben wir in einer isolierten VM ausgeführt, die bei uns ausschließlich der Malware-Analyse dient. Schon der bloße Aufruf war ergiebig, noch ohne jedes Analysewerkzeug. Das Sample war ausgesprochen gesprächig und schrieb ausführliche Statusmeldungen auf die Standardausgabe.

Darin fanden sich ein Key und ein IV (Initialisierungsvektor), mit denen das Binary eine 9.942 Byte große Payload entschlüsselt. Entschlüsselt ist diese 22.528 Byte groß, also zusätzlich gepackt. Dahinter lag eine weitere PE-Datei, die anschließend in den Speicher geladen und ausgeführt wird.

Das Vorgehen ist typisch: Die eigentliche Schadsoftware liegt verschlüsselt vor und wird erst zur Laufzeit entschlüsselt und geladen. Für einen signaturbasierten Scanner, wie er in einfachen Virenschutzlösungen steckt, ist auf der Platte nichts zu sehen, woran eine Signatur greifen könnte. Das erkennbare Muster entsteht erst im Speicher, zu einem Zeitpunkt, an dem viele dieser Scanner nicht mehr hinschauen.

Die entpackte Binary setzt zunächst den Schlüssel HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\GPO-List\test. Danach geht sie die Dienste des Systems durch, greift sich nach nicht offengelegten Kriterien den Dienst AppMgmt heraus und fasst einen weiteren Schlüssel unter HKLM\SYSTEM\CurrentControlSet\Services\AppMgmt an.

An dieser Stelle brach die Ausgabe ab. Auf unserem gepatchten Analysesystem war die Lücke geschlossen, und die Binary verfing sich in einer Endlosschleife.

Also führten wir das Sample auf einem älteren, ungepatchten System aus — und dort ließ sich der vollständige Ablauf beobachten: Die Binary startet Unterprozesse, die einen Administrator-Benutzer anlegen. Nebenbei erklärt das die zwei Dateien. Die Administratorengruppe löst die Malware nämlich nicht zur Laufzeit über ihre bekannte SID auf, sondern trägt sie als festen String im Code: in de.exe als „Administratoren“, in eng.exe als „Administrators“. Ein kleines Detail, das einiges über den Reifegrad des Werkzeugs und seine Zielregion verrät: Wer die Gruppe hart verdrahtet statt über die sprachunabhängige SID aufzulösen, braucht für jede Sprachversion des Zielsystems ein eigenes Binary.

Den Großteil der Binär-Analyse haben agentengestützte Werkzeuge übernommen: Claude Code mit Ghidra-MCP, dazu die Debugging-Tools von Microsoft. Für Reverse Engineering ist das ein dankbarer Ansatz. Die kleinteilige, stumpfsinnige Arbeit wie z. B. Funktionen benennen, den Kontrollfluss nachzeichnen, Hypothesen im Debugger prüfen etc. lässt sich damit straffen, während die eigentliche fachliche Bewertung beim Analysten bleibt. Von der ersten Sichtung bis zum lauffähigen Proof of Concept mit nachvollziehbarem Code verging etwa ein Arbeitstag, jeder Schritt überwacht und gegengeprüft.

Im Kern setzt der Angriff drei Bausteine zusammen: einen Dienst, den auch ein normaler Benutzer starten darf, ein Write-Primitive über den RDPBUS-Treiber, der Symlinks blind folgt und gpupdate, das den Registry-Schlüssel des Dienstes löscht. Zusammengenommen lässt sich die Konfiguration des Dienstes auf eine eigene Binary umbiegen, die anschließend etwa den Administrator anlegt.

In unserem Fall erfüllte der Dienst AppMgmt alle drei Bedingungen.

Im Detail läuft die Kette so ab: Auf anfälligen Systemen vertraut der RDPBUS-Treiber nutzergenerierten Registry-Keys und legt bei der PnP-Enumeration Schlüssel mit den vererbten ACLs des übergeordneten Schlüssels an. Daraus wird ein Write-Primitive, mit dem wir uns per Symlink in den Pfad HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\GPO-List schreiben.

gpupdate räumt diesen frisch angelegten Schlüssel umgehend wieder ab. Über einen weiteren Symlink zielt die Löschung jedoch nicht auf den GPO-List-Eintrag, sondern auf den Registry-Schlüssel des Zieldienstes und erwischt damit ihn.

Eine dritte Runde aus Symlink und RDPBUS-Trigger legt den Schlüssel neu an, diesmal mit den gelockerten Schreibrechten aus dem vererbten ACL. Ab hier lässt sich der Dienst auf eine eigene Binary umleiten, die den Benutzer anlegt. Aufgeräumt wird danach nichts: Der Dienst bleibt für weitere Änderungen offen.

Auf dem Proof of Concept aufbauend haben wir ein Beacon Object File (BOF) entwickelt, das sich in Red-Team-Engagements einsetzen lässt. Es führt den Angriff dynamischer aus und räumt auf Wunsch direkt hinter sich auf: Dienst und ACLs kehren in den Ausgangszustand zurück.

Anfällig bleibt das System danach selbstverständlich weiterhin: angreifbar aber nur noch über die vollständige Kette. Der offen beschreibbare Dienst als bequemer Einstieg für den nächsten Angreifer ist damit wieder verschlossen.

Das BOF legt eine stub.dll auf die Platte, die Befehle im Kontext von PowerShell oder cmd ausführt oder wahlweise Shellcode, eine Binary oder eine DLL des Angreifers nachlädt. Gebaut und kurz abgelegt werden muss dafür nur der Stub selbst.

Am Anfang stand ein einzelnes Sample aus einem IR-Einsatz. Am Ende ergeben sich wertvolle Erkentnisse für die offensive und die defensive Seite. Auf Grund unserer Arbeitsweise ist das deutlich mehr als eine reine Fallbearbeitung im herkömmlichen Sinne hergegeben hätte. Unser IR-Team weiß nun genau, an welcher Stelle der Angreifer seine Rechte ausweitete und woran sich derselbe Mechanismus auf anderen Systemen erkennen lässt: unabhängig davon, welche Payload am Ende steht.

Unser Red Team hat aus derselben Analyse ein Werkzeug für kommende Engagements gewonnen. Und die aufgestellte Detection zielt nicht auf das austauschbare Symptom, sondern eben auf genau den Pflichtschritt der Angriffskette, den der Angreifer nicht weglassen kann.

Der Aufwand dafür war auf unserer Seite überschaubar: von der ersten Sichtung bis zum lauffähigen Proof of Concept ungefähr ein Arbeitstag, ein Gutteil der stumpfen Arbeit an agentengestützte Werkzeuge delegiert, die Bewertung durchgehend beim Analysten. Möglich war dies vorallem weil wir eben unsere Expertisen im Bereich offensive und defensive Security bewusst zusammenführen. Getrennt hätte jede Seite nur die Hälfte gesehen.

Dieser Fall verbindet drei Disziplinen, die bei uns unternehmensweit Hand in Hand zusammenarbeiten:

• Incident Response und digitale Forensik
• offensive Security mit Red Teaming und Penetration Testing
• Detection Engineering.

Wenn Sie einen Verdacht abklären, Ihre Erkennung schärfen oder Ihre Verteidigung gegen reale Angreifertechniken prüfen lassen möchten, sprechen Sie uns an.