Analyse des Notepad++-Supply-Chain-Angriffs

 (securelist.com)
2 Punkte von GN⁺ 2026-02-05 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Supply-Chain-Angriff, bei dem die Update-Infrastruktur von Notepad++ kompromittiert und bösartige Updates verteilt wurden, dauerte von Mitte 2025 bis Oktober an
  • Die Angreifer betrieben drei unterschiedliche Infektionsketten und nutzten dabei Cobalt Strike Beacon sowie einen Metasploit-Downloader
  • Als betroffene Ziele wurden Privatanwender in Vietnam, El Salvador und Australien, eine Regierungsbehörde auf den Philippinen, ein Finanzinstitut in El Salvador sowie ein IT-Dienstleistungsunternehmen in Vietnam identifiziert
  • Die Angriffsmethoden variierten stark, darunter Missbrauch des NSIS-Installers, Ausnutzung einer ProShow-Schwachstelle, Ausführung von Lua-Skripten und DLL-Sideloading
  • Kaspersky erkannte den Angriff mit Kaspersky Next EDR Expert und nannte Kommunikation mit temp.sh, Spuren der Befehlsausführung und Registry-Autorun-Einträge als zentrale Erkennungsindikatoren

Überblick über den Vorfall

  • Am 2. Februar 2026 gab das Notepad++-Entwicklungsteam bekannt, dass der Update-Server auf Ebene des Hosting-Anbieters kompromittiert wurde
    • Der Kompromittierungszeitraum reichte von Juni bis September 2025, der Zugriff auf interne Dienste dauerte bis Dezember an
  • Kaspersky bestätigte, dass die Angreifer zwischen Juli und Oktober 2025 den Angriff fortsetzten und dabei fortlaufend C2-Server-Adressen, Downloader und Payloads austauschten
  • Die Opferzahl war auf wenige Zielsysteme begrenzt; analysiert wurden insgesamt etwa zehn infizierte Computer

Infektionskette #1 (Ende Juli bis Anfang August 2025)

  • Bösartige Update-Datei: http://45.76.155[.]202/update/update.exe
    • SHA1: 8e6e505438c21f3d281e1cc257abdbf7223b7f5a
  • Der legitime Prozess GUP.exe wird ausgeführt und sammelt Systeminformationen, die anschließend an temp.sh hochgeladen werden
    • Die Ergebnisse der Befehle whoami und tasklist werden per curl übertragen
  • Danach werden mehrere Dateien im Ordner %appdata%\ProShow abgelegt und ProShow.exe ausgeführt
    • Eine ProShow-Schwachstelle aus den 2010er-Jahren wird ausgenutzt, um den Metasploit-Downloader in der Datei load auszuführen
    • Der Downloader lädt einen Cobalt Strike Beacon von https://45.77.31[.]210/users/admin herunter und startet ihn
  • Anfang August wurde mit derselben Kette auch eine Variante beobachtet, die die Domain cdncheck.it[.]com nutzte

Infektionskette #2 (Mitte bis Ende September 2025)

  • update.exe, verteilt über dieselbe URL (SHA1: 573549869e84544e3ef253bdba79851dcde4963a)
    • Verwendet den Ordner %APPDATA%\Adobe\Scripts
    • Sammelt detaillierte Systeminformationen mit den Befehlen whoami, tasklist, systeminfo und netstat -ano
  • Abgelegte Dateien: alien.dll, lua5.1.dll, script.exe, alien.ini
    • Ausführung von Shellcode aus alien.ini mithilfe des Lua-Interpreters
    • Der Metasploit-Downloader lädt einen Cobalt Strike Beacon von cdncheck.it[.]com/users/admin herunter
  • Ende September erschien eine Variante, bei der die Upload-URL zu https://self-dns.it[.]com/list und der C2-Server zu safe-dns.it[.]com geändert wurden

Infektionskette #3 (Oktober 2025)

  • Neuer Update-Server: http://45.32.144[.]255/update/update.exe
    • SHA1: d7ffd7b588880cf61b603346a3557e7cce648c93
  • Dateien werden im Ordner %appdata%\Bluetooth\ abgelegt
    • BluetoothService.exe (legitim), log.dll (bösartig), BluetoothService (verschlüsselter Shellcode)
  • Über DLL-Sideloading führt log.dll den Shellcode aus BluetoothService aus
    • Die Struktur ähnelt der Chrysalis-Backdoor; laut einer Rapid7-Analyse gibt es Fälle, in denen zusätzlich ein Cobalt Strike Beacon verteilt wurde

Wiederauftauchen von Kette #2 und URL-Änderungen (Mitte bis Ende Oktober 2025)

  • Neue URL: http://95.179.213[.]0/update/update.exe
    • Die bisherigen Domains self-dns.it[.]com und safe-dns.it[.]com werden erneut verwendet
  • Ende Oktober traten Varianten mit Dateinamen wie install.exe und AutoUpdater.exe auf
    • Nach November wurden keine weiteren Infektionen beobachtet

Fazit und Empfehlungen zur Erkennung

  • Die Angreifer übernahmen den Notepad++-Update-Server, um in risikoreiche Organisationen einzudringen
    • Durch monatliche Änderungen der Infektionskette hielten sie ihren Zugriff dauerhaft aufrecht
  • Empfehlungen für Erkennung und Reaktion
    • Vom NSIS-Installer erzeugte Logs (%localappdata%\Temp\ns.tmp) prüfen
    • Kommunikation mit der Domain temp.sh sowie Anfragen mit eingebetteter URL im User-Agent erkennen
    • Spuren der Ausführung von whoami, tasklist, systeminfo, netstat -ano untersuchen
    • Bösartige Domains und Dateihashes anhand der IoC-Liste suchen

Kaspersky-Erkennung

  • Kaspersky Next EDR Expert erkannte das Angriffsverhalten
    • Kommunikation mit temp.sh wurde durch die Regel lolc2_connection_activity_network erkannt
    • Lokale Aufklärungsbefehle wurden durch Regeln wie system_owner_user_discovery und system_information_discovery_win erkannt
    • Registry-Autorun-Einträge wurden durch die Regel temporary_folder_in_registry_autorun erkannt

Zusammenfassung der wichtigsten IoCs

Dieser Vorfall zeigt die zunehmende Raffinesse von Supply-Chain-Angriffen und die Weiterentwicklung mehrstufiger Infektionsketten und unterstreicht die Notwendigkeit einer strengeren Integritätsprüfung von Updates für Entwickler und Betreiber von IT-Infrastrukturen.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-05
Hacker-News-Kommentare

  • Der Fall, dass das Update-Programm WinGUp für den Angriff missbraucht wurde, ist ein typisches Beispiel für einen Supply-Chain-Angriff
    Angreifer erhalten Code-Ausführungsrechte auf Systemen, die dem Update-Kanal vertrauen
    Besonders besorgniserregend ist, dass dies sechs Monate lang unentdeckt blieb
    Organisationen sollten gestaffelte Rollouts und Monitoring ungewöhnlichen Netzwerkverkehrs erwägen, Privatnutzer die Verwendung von Paketmanagern mit kryptografischer Verifikation

    • Unter Windows ist das Fehlen eines standardisierten Paketmanagers weiterhin ein Problem
      Viele Programme werden von werbeüberladenen Websites heruntergeladen und jeweils auf unterschiedliche Weise aktualisiert
      Der Microsoft Store war eine Chance, das zu ändern, ist aber sowohl beim Design als auch beim Ruf gescheitert
      WinGet ist deutlich besser, aber noch immer eher ein Tool für Entwickler

  • Ich nutze Notepad++ als Standard-Ersatz für den Editor
    Ich habe nie verstanden, warum die Netzwerkverbindung standardmäßig aktiviert war
    Das Erste, was ich getan habe, war, sie zu deaktivieren, und aktuell nutze ich zufrieden die Version von 2020
    Wenn es irgendwann nötig wird, werde ich manuell selbst updaten

  • Notepad++ war einer meiner Lieblingseditoren, aber nach diesem Angriff ist es in der IT-Abteilung verboten worden
    Bei Sicherheitsprüfungen wird sogar kontrolliert, ob es installiert ist

    • Das Vertrauen ist vollständig zerstört
      Auch die Reaktion im offiziellen Blog war beunruhigend, und es dürfte lange dauern, bis das Vertrauen wiederhergestellt ist
    • Sehe ich genauso
      Die zwei entscheidenden Funktionen sind Tabs und Rechtschreibprüfung, und inzwischen unterstützt selbst das Standard-Notepad beides
      Es gibt zwar jetzt einen CoPilot-Button, aber man kann ihn in den Einstellungen deaktivieren

  • Aus genau diesem Grund lasse ich viele Tools in einer Sandbox-Umgebung laufen
    So bleibt der Schaden auf das betreffende Verzeichnis begrenzt
    Es gibt keinen Grund, warum ein Tool Zugriff auf mein Cloud-Laufwerk oder meine Browser-Cookies haben sollte

    • MacOS ist beim UI umstritten, aber in Sachen granulare Berechtigungskontrolle meiner Meinung nach führend
      Die Linux-Community sträubt sich gegen einen solchen Ansatz, aber am Ende sind iOS-artige Sandbox-Apps die Zukunft
      Denn Nutzer wollen kontrollieren, was Apps tun dürfen
      Wenn das FOSS-Lager das ignoriert, wird am Ende alles um große Tech-Konzerne herum zentralisiert
    • Eigentlich sollten alle Apps standardmäßig in einer Sandbox laufen
      Eine App sollte das Root-Verzeichnis nicht verlassen können, und externer Zugriff sollte explizit erlaubt werden müssen
      Die Zugriffsanfragen unter MacOS sind zwar zahlreich, aber ich denke, es braucht feingranularere Rechtekontrolle
    • Beim Ausführen in einer Sandbox ist es auch wichtig, den Internetzugang zu blockieren
      Ein Texteditor braucht keine Netzwerkverbindung und kann den gerade bearbeiteten Text nach außen leaken
      Angreifer senden Systeminformationen, laden Dateien über Dienste wie temp.sh hoch und kommunizieren dann mit einem C2-Server
      Als Beispiel gibt es Code, bei dem ein Cobalt Strike Beacon mit cdncheck.it[.]com kommuniziert
    • Es kam die Frage auf, wie man eine Sandbox unter Windows umsetzt

  • Dieser Angriff zeigt, dass Entwickler und Nutzer immer stärker Code vertrauen, den sie nicht selbst verifiziert haben
    Dasselbe Problem wiederholt sich bei npm/pip-Paketen, AI-generiertem Code und Trends wie „vibe coding“
    Notepad++ ist noch ein vergleichsweise harmloser Fall, weil es nur ein einzelnes Binary ist, aber in modernen Entwicklungsumgebungen hängen Hunderte von Abhängigkeiten und AI-Code zusammen
    Sandboxing ist wichtig, aber das eigentliche Problem ist die Diskrepanz zwischen dem, was Code tun kann, und dem, was man von ihm erwartet
    Wir brauchen Tools, mit denen sich laufender Code besser verstehen lässt

    • Nach meiner Erfahrung nimmt das Vertrauen aber eher ab
      Vor 15 Jahren hat sich niemand um die Supply Chain gekümmert, und Unix-Nutzer haben tarballs ohne Verifikation gebaut
    • Das erinnert an Ken Thompsons klassischen Aufsatz „Reflections on Trusting Trust”
      Sandboxing hilft, ist aber keine perfekte Lösung
      Utilities wie Notepad++, die Berechtigungen zum Bearbeiten von Systemdateien haben, bleiben trotzdem riskant

  • Ich frage mich, ob es ein offizielles Tool gibt, mit dem sich eine Infektion erkennen und bereinigen lässt

    • Unter Windows ist bei einer Infektion das Formatieren der Festplatte und die Neuinstallation des OS die einzige Lösung
      Malware kann sich überall im System verstecken, und UAC-Warnungen allein halten sie nicht auf
    • Es wird empfohlen, den MS Defender im Offline-Modus auszuführen

  • Falls man aktuell infiziert ist: Kann Malwarebytes das erkennen?

    • Im OP-Beitrag gibt es eine Liste mit Indicators of Compromise (IOC)
      Im Rapid7-Analysebeitrag steht dasselbe
      Überraschend, dass dieser Link in der ursprünglichen Mitteilung fehlte
    • Malwarebytes ist aber wegen Qualitätsverlusten zuletzt nicht mehr so nützlich wie früher

  • Ich frage mich, wie die digitale Signatur von Notepad++ umgangen wurde
    Ich habe es direkt heruntergeladen und eine gültige Code-Signatur gesehen

    • Laut offizieller Mitteilung gab es eine Version, die ohne Zertifikat verteilt wurde
    • Das Update-Programm hat das Zertifikat der neuen Installationsdatei nicht geprüft und sie einfach ausgeführt

  • Inzwischen soll man zur Abwehr von Sicherheitslücken häufig updaten, aber um Supply-Chain-Angriffe zu vermeiden, soll man Updates eher zurückhalten — eine widersprüchliche Situation
    Ich weiß nicht, wie man da die richtige Balance findet

    • Früher konnten Updates Systeme auch instabil machen
      Auch aktuelle Microsoft-Updates gelten als unzuverlässig, und wegen Problemen wie nicht mehr bootenden Systemen schalten immer mehr Leute automatische Updates ab
    • Ein lokaler Paketmanager mit einer verzögerten Update-Anwendung wie der Cooldown-Einstellung von Dependabot wäre hilfreich
      Zugehörige Dokumentation: GitHub-Dependabot-Optionen
    • Am Ende ist es ein Trade-off zwischen Zero-Day-Schwachstellen und Supply-Chain-Angriffen
      Apps mit viel Internetanbindung sollte man häufig aktualisieren, bei einfachen lokalen Tools kann man Auto-Updates ruhig deaktivieren
    • Es hängt von der Einsatzumgebung ab
      Wer mit Inhalten aus dem Internet arbeitet, muss updaten; wer nur lokal arbeitet, kann bei Bedarf aktualisieren
      Die meisten Fälle liegen irgendwo dazwischen

  • Als Referenz wurde noch der Analysebeitrag von Rapid7 geteilt