Behörden und mehrere Sicherheitsteams haben eine staatlich unterstützte Kampagne beschrieben, die auf in Korea vertrauenswürdige Webseiten abzielte. Das Muster: Nutzer besuchten kompromittierte Seiten, woraufhin auf ihren Systemen eine Lücke in AnySign4PC ausgenutzt wurde. Ergebnis waren AnySign4PC Hintertüren, die ohne eine vorherige Download-Aufforderung oder eine aktive Nutzerhandlung installiert wurden.
Die Meldung macht vor allem deutlich, wie gefährlich „nur ein Seitenaufruf“ sein kann, wenn lokale Sicherheitssoftware fehlerhaft ist. Außerdem zeigen die Untersuchungen Überschneidungen zu weiteren Vorfällen wie Ransomware-Angriffen, ohne jedoch eine vollständige Zuschreibung zuzulassen.
Warum der Seitenbesuch genügte
In der gemeinsamen Auswertung berichten KISA und Partnerorganisationen, dass eine bereits kompromittierte Webseite Geräte mit einer verwundbaren AnySign4PC-Version erreichen konnte. Dabei ging es nicht um klassischen Drive-by-Download per Klick, sondern um eine Ausnutzung der lokalen Softwareumgebung direkt nach dem Laden der präparierten Seite.
Konkret hebt KISA hervor, dass betroffene Versionen in einem Bereich liegen, in dem ein Buffer Overflow offenbar die Grundlage für Remote Code Execution bildet. Dadurch konnte eine schädliche Komponente starten, ohne dass Nutzer explizit etwas installieren oder herunterladen mussten.
Welche AnySign4PC-Versionen betroffen sind
Laut KISA sind AnySign4PC-Versionen 1.1.4.4 bis 1.1.4.6 anfällig. Als behobene Version wird 1.1.5.0 genannt. Bis zur Umstellung empfiehlt KISA ausdrücklich, gefährdete Installationen zu entfernen.
ENKI Whitehat ordnete AnySign4PC als eines der problematischen Produkte ein und beobachtete die Aktivitäten bereits ab der zweiten Jahreshälfte 2025. KISA veröffentlichte später eine Patch-Notiz im Juni 2026, die diese Schwachstelle adressiert.
So liefen die Angriffe ab: von der präparierten Seite bis zur Hintertür
Die Berichte beschreiben mehrere Bausteine, die zusammen eine typische Angriffskette bilden. In einem von AhnLab beschriebenen Ablauf („Operation Double Barrel“) wurden unter anderem vier PNG-Bilder genutzt, um Schlüssel auszutauschen, die installierte Softwareversion zu prüfen und versionsspezifischen Exploit-Code zu liefern. Anschließend wurde anhand der Ausführungsergebnisse entschieden, ob die Kette fortgesetzt wird.
Die bösartige Seite kommunizierte laut Analyse über WebSocket mit dem lokalen Sicherheitsprogramm. Danach folgte eine Aktion, die in einer Buffer-Overflow-Situation gipfelte und Shellcode ausführen ließ. Das ist wichtig, weil hier bereits ohne User-Download eine lokale Ausführung angestoßen wird.
Danach folgte ein weiterer Schritt: Der Payload wurde in legitime Microsoft-Prozesse injiziert. Je nach Ziel und Kontext installierten die Angreifer dann entweder eine Komponente, die AhnLab dem Muster von SIGNBT zuordnet (als „SIGNBT 3.0“ beschrieben) oder eine weitere Hintertür, die AhnLab mit dem Namen COPPERHEDGE in Verbindung bringt.
Welche Funktionen die Hintertüren mitbrachten
Die installierten Backdoors waren nicht nur „statisch“ abgelegt. Laut AhnLab konnten sie unter anderem Fernkommandos ausführen, Dateien stehlen, interne Erkundungen durchführen, Code in laufende Prozesse injizieren und zusätzliche Payloads nachladen.
Ein weiterer Teil der Analyse kommt von Plainbit: Dort wurde ein watering-hole-Vorfall forensisch rekonstruiert, bei dem Angreifer ein Webshell installiert und JavaScript in eine legitime News-Seite eingeschleust hatten. Besucher erzeugten dadurch eine Fehlermeldung, und das System erzeugte anschließend eine maliziöse DLL, ohne dass eine Download-Prompt oder andere Nutzerinteraktion erforderlich war.
Die anschließende Dynamik umfasste das Entschlüsseln späterer Phasen im Speicher, das Injizieren von Code in svchost.exe sowie das Auslesen von Command-and-Control-Informationen aus dem Windows-Registry-Umfeld.
Bewegung im Netzwerk und technische Nachweisspuren
Um nach der ersten Kompromittierung weiter vorzudringen, nutzten die Angreifer weitere Techniken. In den Berichten tauchen unter anderem Privilege-Escalation-Mechanismen, Tools wie Mimikatz sowie andere Credential-Komponenten auf. Zusätzlich wurden Verbindungen über Remote Desktop Protocol genutzt und Werkzeuge wie NLBrute erwähnt.
S2W beschreibt außerdem wiederkehrende Muster: DLL Side-Loading, verschlüsselte Daten in Registry-Bereichen unter Service-Entries sowie das Laden von Portable Executables direkt im Speicher. Für zwei Cluster wurden Versionen von SIGNBT genannt (u. a. 0.0.1 und 1.2), während ein dritter Loader eine externe Payload entschlüsselte, die die Forschenden nicht vollständig zurückgewinnen konnten.
Zur Spurenverwischung beschreiben die Berichte anti-forensische Schritte. Dazu gehört, dass bösartige Dateien vor dem Löschen in zufällige vierstellige Namen umbenannt werden. Plainbit beobachtete zusätzlich weitere Hinweise wie den Einsatz von SDelete und CCleaner.
Überschneidungen zu Ransomware: der „Gunra Trail“
Besonders interessant sind die Hinweise auf parallele oder wiederverwendete Angriffsmuster. In einem März-2026-Vorfall im Zusammenhang mit Gunra-Ransomware wurde laut AhnLab dieselbe kompromittierte Healthcare-Webseite genutzt. Auch die Schwachstelle aus dem Umfeld der von AhnLab „finanzielle Sicherheitssoftware“ genannten Produkte spielte eine Rolle.
Beide Ketten injizierten Code in SyncHost.exe. Wichtig ist aber: AhnLab benennt „Software A“ nicht konkret, und die Berichte stellen daher nicht sicher, dass die Gunra-Verknüpfung eindeutig die gleiche AnySign4PC-Schwachstelle betrifft.
Trotzdem gibt es klare technische Parallelen: Die Dateinamen net.tmp und inet.tmp tauchen in beiden Operationen auf. Auch das Argumentmuster, ein SSH-Public-Key-Fingerprint sowie eine Reverse-Tunneling-Adresse werden als gleich oder sehr ähnlich beschrieben. Für die Verteilung von Exploit-Skripten wurde außerdem in beiden Fällen die Domain jshosting[.]me genannt.
Die Analysen deuten insgesamt eher auf eine gemeinsame oder wiederverwendete Zugriffs- und Infrastrukturroute hin – allerdings nicht zwingend darauf, dass dieselbe Gruppe beide Operationen vollständig gesteuert hat.
Attribution: staatlich unterstützte Akteure, aber keine vollständige Zuordnung
Die Regierungswarnung und das AhnLab-Dossier bezeichnen den Angreifer als „state-sponsored threat group“, nennen jedoch keine konkrete Gruppierung im Sinne einer eindeutigen Zuordnung. In den Dokumenten wird eine vollständige Zuordnung der gesamten Kampagne von 2025 bis 2026 zu Lazarus nicht formell belegt.
Es gibt jedoch frühere Berichte: AhnLab ordnete einen AnySign4PC watering-hole-Angriff im März 2026 Lazarus zu. Auch Kaspersky dokumentierte Lazarus in Verbindung mit watering holes, süd-koreanischer Sicherheitssoftware sowie SIGNBT und COPPERHEDGE. Diese früheren Publikationen zeigen, dass Lazarus in Zusammenhang mit ähnlichen Methoden und AnySign4PC/Backdoor-Mechanismen bereits zuvor auftrat – sie beweisen jedoch nicht automatisch, dass genau die beschriebenen „Operation Double Barrel“ oder die Gunra-Angriffskette aus derselben Hand stammten.
Was Sie jetzt tun sollten: Patchen und Verhalten jagen
Der Kernpunkt bleibt: Die Lücke betrifft bestimmte AnySign4PC-Versionen, und KISA nennt als Fix 1.1.5.0. Praktisch bedeutet das: Systeme aktualisieren beziehungsweise gefährdete Installationen entfernen, wie es die Behörde empfiehlt.
Darüber hinaus raten die Berichte zu gezielten Suchläufen nach auffälligen Verhaltensmustern. Dazu gehören verdächtige DLL-Ladevorgänge durch legitime Programme, verschlüsselte Daten in Registry-Einträgen rund um Services, die Ausführung von PE-Code im Speicher sowie unerwartete Diensteinrichtungen.
Erwähnt werden außerdem typische „Injektions“-Spuren, etwa Code in SyncHost.exe oder svchost.exe, sowie ungewöhnliche ausgehende SSH-Tunnel.
Warum Beobachtungsdaten wichtiger sind als ein einzelner Dateihash
ENKI fand einen weiteren Punkt, der für Incident Response relevant ist: In bestimmten Betriebsmodi löschte die Hintertür ihre Konfigurations-, Loader- und Backdoor-Dateien vom Datenträger, nachdem sie sie in den Speicher kopiert hatte. Beim späteren Neustart oder bei sauberem Shutdown wurden Dateien wiederhergestellt, mit veränderter Prüfsumme. Das macht „statische Dateisignaturen“ weniger verlässlich und setzt stärker auf Telemetrie und Verhaltensanalyse.
Beispiele für Persistence und Forensik-Plan
Plainbit beschrieb eine Persistence-Kette mit einer geplanten Aufgabe, die ein VBS-Skript startet. Dieses wiederum führte einen umbenannten SSH-Client aus, um eine Reverse-Verbindung aufzubauen. S2W rät, Prozessspeicher, Command Lines, Registry-Werte, DLL-Events sowie Netzwerkaufzeichnungen vor dem Beenden oder Isolieren von Systemen zu sichern.
Mögliche Lieferkettenspuren: kompromittierte Webseiten als Einstieg
Zusätzlich analysierte AhnLab Verbindungen zwischen mehreren kompromittierten Webseiten, die offenbar über ein gemeinsames Entwicklungs- oder Managementunternehmen liefen. Das kann auf eine mögliche Supply-Chain-Route hindeuten – die vorhandenen Belege reichen laut AhnLab aber nicht, um eine Kompromittierung von Quellcode, Update-Prozess oder zentraler Management-Software als Ursache zu belegen.
Unabhängig davon zeigt der Vorfall: Wenn hochwertige Signatur- oder Sicherheitskomponenten durch Schwachstellen ausgenutzt werden, reicht häufig schon der Weg über kompromittierte Webseiten, um späteren Schaden auszulösen.
Fazit
Die beschriebenen Angriffe zeigen eindrücklich, wie AnySign4PC Hintertüren über kompromittierte Seiten entstehen können, ohne dass Nutzer aktiv zustimmen oder etwas herunterladen müssen. KISA nennt betroffene Versionen von 1.1.4.4 bis 1.1.4.6 und als behobene Version 1.1.5.0. Wer betroffen ist, sollte kurzfristig aktualisieren oder gefährdete Installationen entfernen.
Gleichzeitig sollten Sicherheitsverantwortliche im Rahmen der Nachsorge nach typischen Injektions-, Speicher- und Tunnelmustern suchen und dabei vor allem prozess- und netzwerkbezogene Telemetriedaten sichern. So lassen sich solche Kampagnen eher erkennen – auch dann, wenn Dateien im Nachhinein wieder verschwinden.
Quelle: https://thehackernews.com/2026/07/hackers-exploit-anysign4pc-via-hacked.html
