Das Muster, über das niemand sprechen möchte
Die „Locked Shields 2026 “ ging am 24. April in Tallinn zu Ende. Über 4 000 Teilnehmer aus 41 Nationen bildeten 16 multinationale Teams, die sich gegen rund 8 000 Echtzeit-Cyberangriffe auf kritische Infrastrukturen zur Wehr setzten: Luftverteidigung, elektronische Stimmabgabe, 5G, Satellitenmanagement und ein vollständig aufgebautes Stromerzeugungssystem. In den offiziellen Erklärungen wurde, wie stets, die Fähigkeit der Teilnehmer gelobt, „böswillige Cyberaktivitäten aufzudecken und darauf zu reagieren“.
Diese Darstellung entspricht der Wahrheit. Zudem ist es Jahr für Jahr der Aspekt, über den alle sprechen möchten, und er verdeckt dabei still und leise ein weniger schmeichelhaftes Muster: Die blauen Mannschaften, die Schwierigkeiten haben, tun dies nicht, weil ihre SOC-Spielstrategien unzureichend waren. Sie haben Schwierigkeiten, weil unter ihnen etwas zerbrochen ist und sie dies nicht kommen sahen. Sie blickten zu Ebene 7 hinauf, während sich das rote Team bereits auf Ebene 2 befand.
Wenn Sie schon einmal im „Blue Team“ mitgewirkt haben, kennen Sie diese Diskussion. Ein Dienst wird eingestellt. Die ersten zehn Minuten verbringt man damit, die Firewall anzuschreien. Die nächsten zehn Minuten verbringen Sie an der EDR-Konsole. Bis jemand den Befehl „ arp -a “ ausführt oder einen Blick in die BGP-Tabelle wirft, ist die Runde bereits zur Hälfte vorbei.
Dieser Beitrag bietet einen Überblick über das OSI-Modell – nicht, weil das Sieben-Schichten-Modell unantastbar wäre, sondern weil es die übersichtlichste Checkliste für Ingenieure darstellt, die in ein reflexartiges IR-Denken verfallen sind. Wenn Ihre spontane Reaktion auf die Meldung „Der Dienst ist ausgefallen“ lautet: „Überprüfen Sie die WAF“, übersehen Sie dabei fünf Ebenen der Angriffsfläche, in die das Red Team bereits vorgedrungen ist.
Inhaltsverzeichnis
Warum das OSI-Modell nach wie vor seine Berechtigung hat
Alle paar Jahre veröffentlicht jemand einen Beitrag mit der These: „Das OSI-Modell ist tot, nutzen Sie TCP/IP“. Sie haben Recht damit, dass es sich bei dem Modell um eine Abstraktion handelt: Insbesondere die Schichten 5 und 6 dienen in modernen Stacks größtenteils der Verwaltung. Sie irren sich, wenn sie behaupten, dass dies das Ganze nutzlos macht. OSI ist ein Triage-Framework. Wenn etwas defekt ist oder angegriffen wird, ist das Durchgehen der Ebenen von unten nach oben der schnellste Weg, um herauszufinden, wo genau der Fehler liegt – und nicht dort, wo Ihre Tools zufällig Einblick bieten.
Red-Teams wissen das. Sie wählen die Schicht aus, in der Ihre Erkennung am geringsten ist. In einer „Locked Shields“-Umgebung handelt es sich dabei so gut wie nie um Layer 7.
Schicht 1: Physikalische Schicht
In der Übung wird die physikalische Schicht abstrahiert, doch die Lektion lässt sich wie folgt zusammenfassen: Out-of-Band-Management, Konsolenserver, KVMs, Lights-Out-Management-Schnittstellen (iDRAC, iLO, IPMI). Diese werden in der Regel mit Standard-Anmeldedaten oder in gemeinsam genutzten Verwaltungs-VLANs belassen und bieten einen Weg, der alle darüber liegenden Erkennungsmaßnahmen umgeht.
Das ehrliche Versagen des blauen Teams: – das OOB-Netzwerk wurde als „Infrastruktur, die nicht in den Geltungsbereich fällt“ behandelt. Dies fällt in den Geltungsbereich. Wenn „red“ Ihren iDRAC erreichen kann, ist die darüber liegende Firewall reine Dekoration.
Schicht 2: Datenverbindungsschicht
Genau hier entsteht ein unverhältnismäßig großer Teil des Schadens, und es ist die Ebene, über die die meisten erfahrenen Verteidiger gar nicht mehr nachdenken, weil „der Switch das schon regelt“. Der Schalter kann damit nicht umgehen. Der Schalter setzt Ihre Konfiguration durch, die häufig gar keine ist.
Der Angriffskatalog „Layer 2 “ ist nicht neu. Genau darum geht es. All dies ist keine neue Forschung:
- ARP-Spoofing/Cache-Poisoning funktioniert nach wie vor in jedem Segment, in dem keine dynamische ARP-Prüfung (Dynamic ARP Inspection) stattfindet. Verschafft dem Angreifer eine Man-in-the-Middle-Position, die für Ihre L3+-Tools unsichtbar ist
- , das eine CAM-Tabellenüberflutung auslöst, verwandelt einen Switch in einen Hub und sendet Frames, die der Angreifer abfangen kann
- VLAN-Hopping durch Double-Tagging oder DTP-Missbrauch: Ihr „segmentiertes“ Netzwerk ist nur einen falsch konfigurierten Trunk-Port davon entfernt, zu einem flachen Netzwerk zu werden
- DHCP-Engpässe und unerwünschte DHCP- : Vergabe eines eigenen Gateways, um alle Verbindungen darüber zu leiten
- STP-Angriffe auf „ “ geben vor, die Root-Bridge zu sein, verändern die L2 -Topologie und leiten den Datenverkehr zwangsweise über Ihren Tap um
- LLDP/CDP-Injektions t nützlich zur Erkundung und auf einigen Plattformen dazu, benachbarte Geräte zu täuschen
Die Sicherheitsmaßnahmen sind alt, gut dokumentiert und werden chronisch nur unvollständig umgesetzt: Hafensicherheit, DHCP-Snooping, Dynamic ARP Inspection, BPDU Guard, Root Guard, Deaktivierung von DTP, Trennung der Verwaltungs-VLANs. Keines davon ist auf dem Titelblatt eines Whitepapers eines Anbieters abgebildet. Sie alle entscheiden über den Ausgang der Runden.
Das ehrliche Versagen des Blue-Teams: – man vertraute darauf, dass das Netzwerkteam dies bereits in „ 2019 “ erledigt hatte, und hat es nie wieder überprüft. Führen Sie die Prüfungen durch. Sie dauern eine Stunde.
Schicht 3: Netzwerk (und ja, BGP)
Die IP-Schicht ist der Bereich, in dem sich Verteidiger sicher fühlen, doch dieses Sicherheitsgefühl ist fehl am Platz, sobald man sich mit Routing-Protokollen befasst.
Beim internen Routing (OSPF, EIGRP, IS-IS) wiederholt sich dasselbe Muster wie in L2 . Die Authentifizierung ist im Protokoll optional, in der Praxis jedoch zwingend erforderlich und wird „vorerst“ in Labor- und Übungsumgebungen routinemäßig deaktiviert, was sich schließlich in den Reflexen der Produktionsumgebung niederschlägt. Ein Angreifer in einem Peering-Segment ohne OSPF- MD5/SHA-Authentifizierung kann Routen einschleusen, Datenverkehr ins „Black Hole“ leiten oder ihn unbemerkt umleiten.
Dann gibt es noch BGP. BGP betreibt das Internet auf der Grundlage eines Vertrauensmodells, dessen Wurzeln bis zu den RFCs 1105 und 1989 zurückreichen, und in „Locked Shields“-Szenarien wird es zunehmend einbezogen, da dies auch bei realen Angreifern der Fall ist. Die relevante Angriffsfläche:
- Routen-Hijacking: – die Ankündigung eines spezifischeren Präfixes, das Ihnen nicht gehört, um Datenverkehr auf sich umzuleiten
- Routenlecks: – die Weitergabe von Routen, die von einem Peer gelernt wurden, an einen anderen Peer unter Verstoß gegen die Richtlinien, häufig versehentlich, mit denselben betrieblichen Auswirkungen wie bei einer Routenentführung
- Sitzungsabbrüche: „ “ nutzt manipulierten TCP-Datenverkehr, um BGP-Sitzungen zu beenden. Aus diesem Grund gibt es TCP-AO (RFC 5925) bzw. – historisch gesehen – TCP MD5
- Pfadmanipulation: – Einfügen von AS-Pfaden und Missbrauch von Community-Einstellungen, um den Datenverkehr auf eine Weise umzuleiten, die von Ihrer Überwachung nicht erfasst wird, da die Routen weiterhin „gültig“ sind
Die Schutzmaßnahmen sind operativer Natur und nicht produktbezogen: RPKI-Herkunftsvalidierung, Begrenzung der maximalen Präfixanzahl, Präfixfilter bei jeder eBGP-Sitzung, Peer-Authentifizierung sowie BGPsec, sofern verfügbar. Wenn Ihre Antwort auf die Frage „Sind wir anfällig für ein Routenleck aus unserem Upstream?“ lautet: „Die Firewall wird das abfangen“, dann wird sie das nicht tun. Die Firewall erkennt die eingehenden Pakete. Es kann nicht erkennen, dass sie über einen Weg gekommen sind, der eigentlich gar nicht existieren dürfte.
Das ehrliche Versagen des „Blue Teams“: – das Routing wird als „Problem des Netzwerkteams“ betrachtet, das von der Sicherheit isoliert ist. Sowohl in der Theorie als auch in der Praxis ist das Routing gleichbedeutend mit Sicherheit.
Schicht 4: Transport
Hier gibt es zwar weniger Drama, doch die Grundlagen sind nach wie vor wichtig: SYN-Flood-Schutz, sinnvolle TCP-Timeouts, das Bewusstsein, dass eine inaktive TCP-Sitzung missbraucht werden kann, wenn Sequenznummern nach außen dringen, sowie UDP-Amplifikationsvektoren bei jedem Dienst, den Sie offenlegen (DNS, NTP, memcached, CLDAP). Die meisten Verteidiger meistern diese Aufgabe kompetent. Der Fehler bei L4 liegt in der Regel nicht in der Erkennung. Es handelt sich um „ “ unter. Dienste sind von Segmenten aus erreichbar, von denen aus sie eigentlich nicht erreichbar sein sollten.
Schichten 5 und 6: Sitzung und Darstellung
In der Praxis bedeutet dies: „TLS und alles, was damit zusammenhängt.“ Schwache Verschlüsselungsalgorithmen, abgelaufene oder nicht ordnungsgemäß validierte Zertifikate, Fehlkonfigurationen bei der Wiederaufnahme von Sitzungen, „Mutual TLS“, das in Wirklichkeit nicht gegenseitig ist, da der Server die Zertifikatskette des Clients nicht überprüft. In „Locked Shields“-Szenarien wird regelmäßig eine fehlerhafte TLS-Konfiguration als gezielte Falle eingebaut. Sicherheitsbeauftragte, die lediglich überprüfen, ob „HTTPS aktiviert ist“, übersehen dies.
Ein weiteres unterschätztes Problem im Zusammenhang mit „ L5/6 “ ist die Verwaltung von Anwendungssitzungen: vorhersehbare Sitzungs-IDs, Token, die nicht rotieren, sowie JWTs, die nicht signiert sind. Es handelt sich hierbei um L7 Schwachstellen im Sinne der OWASP, doch sie liegen an der Schnittstelle zwischen Sitzung und Präsentation, und auf diese Weise verschafft sich ein Angreifer, der bereits einen Fuß in der Tür hat, Zugang zu einer dauerhaft bestehenden Identität.
Schicht 7: Anwendung
Hier befinden sich tatsächlich die meisten Verteidigungsinstrumente, weshalb die meisten Verteidiger standardmäßig an dieser Stelle ansetzen. Web-Sicherheitslücken, Malware-Verhalten, Missbrauch von Authentifizierungsverfahren, Fehler in der API-Logik. Nichts davon ist unwichtig, es ist lediglich altbekannt, und Ihr Stack berücksichtigt dies bereits. Die Tendenz, die es zu korrigieren gilt, ist genau die umgekehrte: Wenn Sie nach dreißig Minuten seit Beginn eines Vorfalls immer noch nach einer „ L7 “-Erklärung suchen, obwohl die Symptome nicht dazu passen, gehen Sie den Stapel noch einmal von oben nach unten durch.
Die Firewall ist nicht das Wesentliche
Eine Arbeitshypothese, die sich aus jahrelangen Nachberichten zu „Locked Shields“-Übungen sowie aus den jeweiligen Haupttätigkeiten, aus denen diese stammen, ergibt: Der durchschnittliche erfahrene Ingenieur des „Blue Teams“ misst der Erkennung zu viel und der Konfiguration zu wenig Bedeutung bei. Die Erkennung ist das, womit sich ihre Tools verkaufen. Die Konfiguration entscheidet letztendlich über Sieg oder Niederlage in der Runde.
Eine nützliche Checkliste mit den ersten 5 Schritten vor dem Einsatz für einen erfahrenen Verteidiger, in der Reihenfolge, in der ein Angreifer diese Schritte durchdenkt:
- Sind auf jedem Access-Switch die Layer- 2 -Sicherheitsmaßnahmen umgesetzt: Port-Sicherheit, DHCP-Snooping, DAI, BPDU Guard, kein DTP, separates Management-VLAN?
- Werden die Sitzungen der Routing-Protokolle authentifiziert, wobei bei jedem eBGP-Peer „max-prefix“- und „prefix“-Filter eingesetzt werden? Wird die RPKI-Validierung tatsächlich durchgesetzt und nicht nur aktiviert?
- Befinden sich die Verwaltungsebenen (OOB, iDRAC/iLO/IPMI, Switch-Verwaltung, Hypervisor-Konsolen) in einem Segment, das für einen Angreifer von einem kompromittierten Benutzerendpunkt aus nicht erreichbar ist?
- Wird die TLS-Konfiguration überprüft und nicht einfach vorausgesetzt: einschließlich der Validierung des Client-Zertifikats, wenn mTLS angegeben wird?
- Dann der L7 -Stack: WAF-Regeln, EDR-Abdeckung, SIEM-Erkennungen, IR-Playbooks.
Die Reihenfolge ist entscheidend. Bei den ersten vier Punkten gehen Runden unbemerkt verloren, noch bevor die IR-Phase von „ “ überhaupt beginnt. Zudem sind dies die Punkte, die am seltensten in einer Folie zur vierteljährlichen Überprüfung auftauchen, da sie keine Warnmeldungen auslösen, solange sie ordnungsgemäß funktionieren.
Wo Tanium zum Einsatz kommt (sobald die Grundlagen stimmen)
Ich möchte hinsichtlich des Umfangs ehrlich sein. Tanium führt keine Authentifizierung Ihrer BGP-Peers durch. Die dynamische ARP-Prüfung wird auf Ihren Access-Switches nicht konfiguriert. Die ersten vier Punkte der obigen Checkliste beziehen sich auf die Netzwerktechnik, und keine Endpunktplattform kann diese Arbeit ersetzen.
Doch sobald Sie den Stapel wieder nach oben durchgehen, ändert sich das Bild. Denn sobald die Netzwerkebene korrekt konfiguriert ist, stellt sich die nächste Frage: Wissen Sie eigentlich, welche Anwendungen auf jedem Endgerät ausgeführt werden? Ist es gepatcht, abgesichert und so konfiguriert, wie Sie es sich vorstellen? Die Dienste so ausführen, wie es vorgesehen ist, und nicht mehr als das?
Das ist die Ebene, auf der wir Tanium bei „Locked Shields 2026“ implementiert haben. Während des Live-Zeitraums bot die Plattform Folgendes:
- Echtzeit-Bestandsaufnahme aller Hosts in der Infrastruktur für Windows und Linux, einschließlich der Segmente, die wir im Verlauf der Übung integriert haben
- Die Software-Stückliste und die Transparenz auf Bibliotheksebene decken jeden Endpunkt ab, bis hin zu einzelnen Komponenten und Versionen
- Sicherheitslücken-Daten, die direkt mit der Behebung verknüpft sind: – Suchen Sie die betroffene Bibliothek und führen Sie die Korrektur über dieselbe Konsole durch
- Automatische Bereitstellung des Tanium-Agenten auf neu erkannten Hosts, ohne manuelle Einreihung in eine Warteschlange
- Die Verteilung und Aktualisierung der AV- und EDR-Agenten von erfolgt parallel zu Tanium über eine einzige Konsole für den gesamten Gerätebestand
- Patches von Drittanbietern für Betriebssysteme und „ “ in großem Maßstab , wie z. B. kumulative Windows-Updates, .NET-, SharePoint-, Linux-Kernel- und Bibliotheks-Patches
- Sicherheitshärtungsskripte wurden im gesamten Netzwerk bereitgestellt und erneut angewendet, sodass kein Host unkonfiguriert blieb
- Die Rotation lokaler Anmeldedaten, die in kurzen Intervallen v implementiert wurde, dient dazu, die Nutzungsdauer gestohlener Passwörter zu begrenzen.
- Maßgeschneiderte Pakete zur Reaktion auf Vorfälle , die unter Zeitdruck erstellt und an die gesamte Flotte verteilt wurden; diese umfassen die Bereitstellung von Firewall-Regeln, die Beseitigung von Persistenzmechanismen sowie die Entfernung von Implantaten
- zur Bedrohungssuche über die gesamte Endpunktinfrastruktur hinweg von einer einzigen Konsole aus
- Agentenbasierte Befehlsübermittlung als Ausweichlösung bei Beeinträchtigungen der Standard-Netzwerkpfade
Nichts davon ersetzt es, Layer 2 richtig zu gestalten. Das Ganze funktioniert nicht mehr, wenn Sie nicht wissen, über welche Endpunkte Sie verfügen. Die beiden Disziplinen ergänzen sich. Die Teams, die bei Locked Shields gut abschneiden, betreiben beides parallel: eine abgesicherte Netzwerkebene im Hintergrund und eine vollständig verwaltete, lückenlos überblickbare Endgeräteumgebung im Vordergrund.
Das Fazit
„Locked Shields“ ist beeindruckend, und die darin gezeigten IR-Anwendungen sind echt. Doch diese Übung zeigt auch Jahr für Jahr, dass erfahrene Verteidiger in den grundlegenden Ebenen die Oberhand behalten. Das Team, das ARP und DHCP im Zugangssegment gesichert, seine Routing-Sitzungen authentifiziert und seine Verwaltungsebene segmentiert hat, wird im Durchschnitt das Team mit dem ausgefeilteren SOAR-Playbook übertreffen.
Wenn Sie aus diesem Beitrag nur eine Sache mitnehmen möchten: – sollten Sie das nächste Mal, wenn etwas nicht funktioniert und Ihr erster Reflex darin besteht, die Firewall-Konsole zu öffnen, zunächst folgende Befehle ausführen: show mac address-table oder show ip bgp summary . Die Antwort lautet häufiger „ja“, als Sie zugeben möchten. Sobald die Netzwerkebene einwandfrei funktioniert, stellen Sie sicher, dass darüber eine echte Endpunktplattform vorhanden ist. Zunächst einmal die Grundlagen. An zweiter Stelle steht die Plattform. In dieser Reihenfolge.
Zahlen und Zitate zu „Locked Shields 2026 “ stammen von , CCDCOE, , SHAPE NATO sowie Details zum Übungsszenario, die über bestätigt wurden, SANS Institute.
Titelbild von: Blue Team 10 @ Locked Shields
