OPSEC-Fehler: Wie Fehler von Angreifern Verteidigern helfen

Aktualisierung vom 1. September 2026: Es wurde ein vierter Fall hinzugefügt, der auf die Anklagen vom August 2026 gegen zwei mutmaßliche Betreiber von TeamPCP zurückgeht, sowie ein abschließender Abschnitt darüber, welche Möglichkeiten diese Sicherheitslücken den Verteidigern bieten und welche nicht.

--

Ein Team von „ ransomware “ startete ein Partnerprogramm mit eigenen, über das Internet zugänglichen Verwaltungssystemen. Eine Gruppe, die behauptete, einen Sicherheitsverstoß entdeckt zu haben, hatte in Wirklichkeit in einem Honeypot herumgeschnüffelt. Ein Entwickler, der an staatlichen Cyberoperationen arbeitete, hatte einen handelsüblichen Infostealer auf seinem eigenen Rechner laufen.

Angreifer investieren in Tools, Infrastruktur und Umgehungsmaßnahmen und bemühen sich, einen disziplinierten Eindruck zu vermitteln. Die nachstehenden Berichte deuten darauf hin, dass diese Investitionen ungleichmäßig verteilt sind.

Im Folgenden werden vier dokumentierte OPSEC-Verstöße aufgeführt. Die ersten drei wurden im Dezember 2025 von Forschern gemeldet, der vierte im August 2026. Ich habe sie nach den jeweiligen Verstoßbereichen gruppiert: Prozess, Verhalten, technische Isolierung und Identität.

Devman: Verfahrensfehler bei der OPSEC in ransomware

In einem früheren Artikel habe ich die technischen Details der ransomware behandelt, darunter ihre Funktionsweise und welche Elemente aus bestehendem ransomware wiederverwendet wurden.

Nach dem Start wurde Devman auf X öffentlich kritisiert, weil Forscher die Sicherheitsvorkehrungen als „mangelhaft“ bezeichneten . Ein Bericht von Ctrl Alt Intel dokumentierte, wie eine Gruppe bei der Einführung eines „ ransomware-as-a-Service“-Angebots ihre eigene Infrastruktur offenlegte.

Die gemeldeten Probleme:

• Bei der Einführung wurde die interne Infrastruktur offengelegt: Die zur Betriebsführung genutzten Systeme, einschließlich interner Dienste, waren über das Internet erreichbar.
• Die Verwaltungs- und Kommunikationssysteme waren nur unzureichend geschützt, sodass Forscher beobachten konnten, wie Teile des Betriebsablaufs koordiniert wurden.
• Wiederverwendung von Werkzeugen ohne Härtung: Der Vorgang wurde an vorhandenen Komponenten durchgeführt, die nicht unter OPSEC-Gesichtspunkten geprüft worden waren.

Der Start erfolgte, bevor irgendetwas davon abgeklärt war. Für ein Unternehmen, das Partner rekrutiert, führte dies dazu, dass es in der Öffentlichkeit den Ruf erlangte, einen unausgereiften Betrieb zu führen.

Scattered Lapsu$ Hunters: Verhaltensbezogene OPSEC-Verstöße bei der Zielüberprüfung

Mitfolgendem verbundene Schauspieler SLSH behaupteten öffentlich, es habe einen Hackerangriff auf ein Cybersicherheitsunternehmen gegeben, veröffentlichten Screenshots und gaben an, dass sensible Daten gestohlen worden seien.

Aus den nachfolgenden Berichten ging hervor, dass es sich bei den Systemen, auf die sie zugreifen konnten, nicht um Produktionssysteme handelte. Sie enthielten synthetische Daten – eine Täuschungstechnik, die Resecurity hier dokumentiert und die so konzipiert war, dass sie einem flüchtigen Blick standhalten würde.

Die Misserfolge:

• Keine Überprüfung der Zielumgebung: Es wurde davon ausgegangen, dass die zugänglichen Systeme echt waren, ohne zu prüfen, ob sie isoliert oder überwacht wurden.
• Synthetische Daten wurden als Nachweis für einen Angriff akzeptiert, da sie wie echte Daten aussahen.
• Wiederholte Abruf- und Zugriffsversuche führten zu Proxy-Fehlern, durch die technische Details preisgegeben wurden, die für die Nachverfolgung nützlich waren.

Die Behauptung wurde öffentlich gemacht, bevor sie bestätigt war, und als sie widerlegt wurde, verlor die Gruppe damit auch ihre Glaubwürdigkeit .

Nordkoreanischer Betreiber: Technische OPSEC-Mängel bei der Systemisolierung

Ein Rechner, der von einem an nordkoreanischen Cyberoperationen beteiligten Entwickler genutzt wurde , war selbst mit „LummaC2“ infiziert , einer weit verbreiteten Malware zum Diebstahl von Informationen malware. Bei der Analyse der Protokolle wurden Anmeldedaten und Tools auf dem Gerät entdeckt, und die Ermittler brachten es mit einer Infrastruktur in Verbindung, die mit dem Diebstahl von Kryptowährungen bei Bybit in Verbindung steht, der nordkoreanischen Akteuren, darunter der Lazarus-Gruppe, zugeschrieben wird. Bei dieser Meldung handelt es sich eher um eine sekundäre als um eine primäre Warnung; behandeln Sie die Einzelheiten daher mit der gebotenen Vorsicht.

Die gemeldeten Fehler:

• Mangelhafte „ endpoint “-Sicherheit: Ein vom Angreifer kontrolliertes System wurde durch einen handelsüblichen Infostealer kompromittiert.
• Keine Isolierung: Tooling, „ phishing “-Domains und Betriebsressourcen befanden sich auf einem einzigen Rechner, und die dort gespeicherten Anmeldedaten ließen sich auf eine bekannte bösartige Infrastruktur zurückführen.
• Unvollständige Anonymisierung: Durch die Nutzung eines VPN wurden die Browserkonfiguration, die Spracheinstellungen und die Nutzungsmuster nicht verschleiert.

Im Mai 2025 infizierten die Entwickler hinter der DanaBot- malware versehentlich ihre eigenen Rechner, und die Ermittler nutzten später die wiederhergestellten Anmeldedaten.

Beide Fälle zeigen, wie Angreifer Opfer derselben Bedrohungen werden können, die sie selbst einsetzen.

TeamPCP: Identitäts-OPSEC-Verstöße im Persona-Management

Die manipulierten Trivy- und LiteLLM-Versionen, über die ich im Juli berichtet habe, werden laut der FLASH-Warnmeldung des FBI vom 2. Juli der Gruppe „TeamPCP“ zugeschrieben. Am 27. August 2026 erhob die australische Bundespolizei (AFP) nach einer gemeinsamen Operation der AFP, des FBI und der Polizei von Westaustralien Anklage gegen zwei Männer aus Westaustralien. Bei diesen Anklagepunkten handelt es sich um Vorwürfe, die noch nicht vor Gericht geprüft wurden.

Das „Emerging Threats“-Team von Flare veröffentlichte noch am selben Tag eine Schritt-für-Schritt-Anleitung zur De-Anonymisierung, und Brian Krebs berichtete separat über die Anklagepunkte. Der Ausgangspunkt ist der wichtige Teil, nicht das Ergebnis.

Flare begann mit einem einzigen Alias, der bereits bei früheren TeamPCP-Operationen verwendet worden war und der unverwechselbar genug war, um direkt danach zu suchen. Dies führte zu einem Bug-Bounty-Profil mit einem echten Namen sowie zu einem Profil in einer Machine-Learning-Community, in dem öffentlich eine Domain aufgeführt war, die später als Command-and-Control-Infrastruktur für die „Mini-Shai-Hulud“- worm genutzt wurde. Von dort aus führte die Spur über durchgesickerte Zugangsdaten: eine E-Mail-Adresse einer Bildungseinrichtung, ein in einem öffentlichen Datensatz offengelegtes Passwort und schließlich ein persönliches E-Mail-Konto, das durch Pivoting anhand dieses Passworts wiederhergestellt wurde. Ein damit verknüpftes Konto wies dasselbe Profilbild auf, das auch den Telegram-Kanal der Gruppe zierte.

Die Misserfolge:

• Ein einheitlicher Alias, der sowohl in operativen als auch in privaten Konten verwendet wird und sowohl in den TeamPCP-Tools als auch in einem Profil mit einem echten Namen auftaucht.
• In einem persönlichen Profil aufgeführte operative Infrastruktur: Laut Flare war eine C2-Domain, die im Mai 2026 im Rahmen der „ worm “-Kampagne verwendet wurde, in einem persönlichen Konto öffentlich einsehbar.
• Wiederverwendung von Passwörtern: Ein einziger Zugangsdatensatz in einem öffentlich zugänglichen Daten-Dump stellte eine Verbindung zwischen einer Schul-E-Mail-Adresse und einem privaten Konto her – und dieses Konto wiederum mit allen damit registrierten Konten.

Das ist alles keine technische Angelegenheit. Flare selbst zieht in seinen Empfehlungen an Verteidiger eine klare Grenze: Überwachen Sie Ihre Domains in Stealer-Logs und Combolists. Die Offenlegung von Anmeldedaten, durch die Forscher eine echte Identität ermitteln konnten, gehört zur gleichen Kategorie von Datenlecks, die 2.500 Organisationen in das Archiv von TeamPCP gebracht haben.

TeamPCP machte zudem bewusst viel Aufsehen: Telegram-Kanäle, ein inzwischen gelöschter X-Account, Sticheleien gegen die Opfer und der unter einer MIT-Lizenz veröffentlichte Quellcode von „ worm “ mit einem beigefügten Scherz. Die Gruppe gab außerdem Forbes ein Interview, in dem sie sich selbst als „eine lose Gruppe von Teenagern und jungen Erwachsenen, die keine bezahlte Arbeit finden konnten und sich deshalb der Cyberkriminalität zuwandten“ beschrieb. All dies waren Ansatzpunkte für die Ermittlungen.

Was diese Fehler den Verteidigern tatsächlich bringen

Ctrl Alt Intel dokumentierte die Verwaltungssysteme von Devman, indem es dessen Infrastruktur von außen auswertete. Der Infostealer auf dem Rechner des nordkoreanischen Betreibers tauchte bei der Log-Analyse einer anderen Person auf. Die Kette von Flare begann mit einem öffentlichen Alias und basierte auf öffentlich zugänglichen Daten. In allen vier Fällen gelangte der Fehler erst im Nachhinein durch Recherchen an die Öffentlichkeit und nicht durch die Überwachung durch das Opfer selbst.

Diese Unterscheidung ist wichtig, da der typische Fall wie folgt aussieht:

• Ein Angreifer, der native Admin-Tools und signierte Binärdateien verwendet, hinterlässt keine „ malware “, die gescannt werden könnten: Es sieht alles normal aus.
• Wer echte Anmeldedaten und ein echtes Token vorlegt, erzeugt einen fehlerfreien Eintrag im Anmeldeprotokoll: Die Authentifizierung ist erfolgreich.
• Da sich die Ebenen „On-Premises“, „Identität“ und „ cloud “ überschneiden, gibt es kein einziges System, das den Gesamtüberblick bietet: Bewegungen sind nicht sichtbar.

Das sind die drei Schwachstellen , über die ich schreibe, und keiner der vier oben genannten Fehler hat während der Ausführung der Angriffe etwas an ihnen geändert.

Devmans offenes Dashboard half den Forschern dabei, einen Vorgang zu analysieren – nicht aber einem Opfer, einen Einbruch zu entdecken. Der Walkthrough von Flare führte zu einer Zuordnung, nicht zu einer Warnmeldung. Diese Fehler dienen der Zuordnung, der Strafverfolgung und der öffentlichen Berichterstattung – allesamt wichtige Aspekte, von denen jedoch keiner die Erkennung betrifft. Bei der Erkennung muss davon ausgegangen werden, dass kein Fehler gemacht wurde.

Was diese Fehlschläge jedoch deutlich machen, ist die Art von Anzeichen, auf die man achten sollte. In jedem Fall handelte es sich eher um verhaltensbezogene als um statische Hinweise : wie sich der Angreifer nach dem Zugriff verhielt, welche Infrastruktur wiederverwendet wurde und wo die Isolierung versagte. Täuschungsumgebungen, synthetische Daten und verhaltensbasierte Überwachung verhindern keine Angriffe. Sie decken Verhaltensmuster auf, wenn eine Annahme nicht zutrifft.

Angreifer setzen zudem auf KI-gestützte Tools, die die Erkundung, Zielauswahl und Ausnutzung beschleunigen, ohne dabei das menschliche Urteilsvermögen aus dem Prozess auszuschalten. Dies bringt eigene Fehlerquellen mit sich: das übermäßige Vertrauen in automatisierte Ergebnisse und die Ausweitung einer falschen Annahme, bevor jemand bemerkt, dass sie falsch war.

Die Kapitel über Lücken in „Mind Your Attack Gaps“ beschreiben, wie die Erkennung aussieht, wenn der Angreifer alles richtig macht – und genau darauf sollte man sich bei der Planung vorbereiten. Bei „ Vectra AI “ modellieren wir das Verhalten anhand des Zugriffs über Identitätsdaten, „ cloud “ und das Netzwerk, da dieses Signal auch dann erhalten bleibt, wenn der Angreifer keinerlei Fehler macht.

Die Technologie verändert sich. Die Menschen nicht.