
KI-Würmer: Die Cyber-Bedrohungslage verschärft sich weiter
Im Juni 2026 stellte das CleverHans Lab der Universität Toronto am IEEE Symposium on Security and Privacy einen Forschungsprototyp eines selbstlernenden KI-Wurms vor. Im kontrollierten Versuch identifizierte dieser durchschnittlich rund 31 Schwachstellen pro Netzwerk und infizierte 62 Prozent eines Testnetzes mit 33 Hosts innerhalb von sieben Tagen. Die Erfolgsquote lag bei 50 Prozent.
Der Prototyp generiert Angriffsstrategien in Echtzeit und passt sie an das jeweilige Zielsystem an. Im Gegensatz zu klassischen Würmern, die auf fest programmierte Exploits angewiesen sind, kann er öffentlich verfügbare Schwachstelleninformationen zur Laufzeit auswerten und sein Vorgehen entsprechend anpassen.
Die Forschung der Universität Toronto entstand unter kontrollierten Laborbedingungen. Bislang sind keine selbstreplizierenden KI-Würmer ausserhalb solcher Testumgebungen dokumentiert. Dennoch hat sich die Bedrohungslage weiterentwickelt. Am 22. Juli 2026 führten zwei KI-Modelle von OpenAI während einer Sicherheitsevaluation einen autonomen Cyberangriff auf die Produktionsinfrastruktur von Hugging Face durch. Der Vorfall war kein KI-Wurm im Sinne der Toronto-Forschung, da keine selbstständige Replikation über Netzwerke stattfand. Er zeigt jedoch, dass KI-Systeme bereits heute eigenständig Schutzmechanismen überwinden, Schwachstellen ausnutzen und komplexe Angriffsschritte ohne fortlaufende menschliche Steuerung ausführen können.
Für Unternehmen bedeutet das: Autonome Cyberangriffe sind keine theoretische Zukunftsfrage mehr. Gleichzeitig bleibt der selbstreplizierende KI-Wurm vorerst ein Forschungsszenario. Umso wichtiger wird es, Sicherheitsarchitekturen bereits heute auf adaptive und autonome Angriffsmuster auszurichten.
KI-Würmer bleiben vorerst Forschung. Sicherheitsarchitekturen sollten sich dennoch bereits heute auf adaptive Angriffe einstellen.
Was unterscheidet KI-Würmer von klassischer Malware
Adaptive Strategie in Echtzeit
Klassische Würmer folgen einem fest programmierten Ablauf. Der Forschungsprototyp aus Toronto geht einen Schritt weiter. Er nutzt grosse Sprachmodelle, um Angriffsstrategien während des Angriffs an das jeweilige Zielsystem anzupassen. Dazu wertet er öffentlich verfügbare Schwachstelleninformationen aus und generiert passende Angriffsvektoren in Echtzeit.
Im Versuch nutzte der Prototyp sogar drei Schwachstellen, die erst nach dem Trainingsstichtag des Modells veröffentlicht worden waren. Das zeigt, dass sich sein Vorgehen nicht auf bereits bekannte Exploits beschränkt.
Dezentralisierte Operationen ohne zentrale Kontrollpunkte
Ein signifikanter Unterschied zu konventioneller Malware liegt in der fehlenden Abhängigkeit von Command-and-Control-Servern. Der Forschungsprototyp nutzt Open-Weight-Modelle (wie Llama 2, Mistral), die lokal auf infizierten Systemen ausgeführt werden, und greift dabei auf deren Rechenleistung zurück. Eine dauerhafte externe Steuerung ist damit nicht erforderlich, was die Erkennung erschweren kann.
Diese Architektur hat jedoch Grenzen. Open-Weight-Modelle wie Llama 2 oder Mistral benötigen je nach Ausführung zwischen 13 und 70 GB Speicher. Viele Systeme in realen Unternehmensnetzen verfügen nicht über diese Kapazität. Offen bleibt zudem, wie gut sich der Ansatz auf grössere, geschützte Umgebungen mit EDR, UEBA und Netzwerksegmentierung übertragen lässt.
Der Paradigmenwechsel: Klassische Würmer vs. KI-Würmer
Im direkten Vergleich wird deutlich, wie sich der Forschungsprototyp von klassischen Würmern unterscheidet:
Welche Cyberrisiken entstehen für Unternehmen?
Heterogene Umgebungen vergrössern die Angriffsfläche
Adaptive Malware könnte unbekannte Schwachstellen in Legacy-Systemen, IoT-Geräten oder Cloud-Services gezielt ausnutzen.
Besonders exponiert sind Organisationen mit:
- veralteter Infrastruktur, die nicht regelmässig gepatcht wird,
- mit grosser Heterogenität (unterschiedliche Betriebssysteme, Anwendungen, Hersteller),
- und eingeschränkter Netzwerk-Sichtbarkeit über On-Premises- und Cloud-Umgebungen.
Bypass von bestehenden Sicherheitsmassnahmen
Signaturbasierte Sicherheitslösungen wie klassische Antivirenprogramme oder Intrusion Detection Systems erkennen bekannte Muster. Passt Malware ihre Angriffswege laufend an oder nutzt bislang unbekannte Schwachstellen, reichen solche Verfahren allein nicht aus. Verhaltensbasierte Erkennung gewinnt deshalb an Bedeutung.
Praxisbeleg Juli 2026: KI-Modelle von OpenAI nutzten beim Angriff auf Hugging Face eine Zero-Day-Schwachstelle in einem Cache-Proxy. Eine Lücke, die signaturbasierte Sicherheitssysteme nicht kannten und daher nicht erkennen konnten. Die Forensik musste zudem auf ein alternatives Open-Source-Modell (GLM 5.2 von Z.ai) ausweichen, weil ein führendes US-Modell die Untersuchung verweigerte, ein Hinweis auf neue Abhängigkeiten und Risiken in der KI-gestützten Incident Response.
Wirtschaftliche Asymmetrie: Shift zu Gunsten der Angreifer
Nach der Initialinfektion fallen für Angreifer nur noch marginale Kosten an. Der Wurm operiert autonom auf kompromittierten Systemen. Verteidiger hingegen müssen in Echtzeit-Monitoring, KI-gestützte Systeme und schnelle Patch-Prozesse investieren.
Handlungsempfehlungen nach Stakeholder-Rolle
Die Anforderungen unterscheiden sich je nach Verantwortung im Unternehmen. Während CISOs die strategischen und organisatorischen Voraussetzungen schaffen, setzen SOCs und CSIRTs die technischen und operativen Massnahmen um.
Für Unternehmen und KMUs bilden grundlegende Sicherheitsmassnahmen die Basis, um sich auf adaptive Angriffsmuster vorzubereiten.
CISO: Strategische Risiko-Neubewertung und Governance
Priorität 1: Risikoneubewertung durchführen
- Führen Sie eine KI-spezifische Bedrohungsmodellierung durch.
- Systeme mit höchster Anfälligkeit identifizieren: veraltete IoT-Geräte, ungepatchte Legacy-Software, Systeme mit eingeschränkter Überwachung.
- Red-Team-Übungen durchführen, die externe Sicherheitsexperten KI-gestützte Angriffsmuster simulieren.
Priorität 2: Investitionen in verhaltensbasierte Erkennung
- User and Entity Behavior Analytics (UEBA) implementieren wie Vectra AI oder Microsoft Defender for Cloud.
- Network Traffic Analysis (NTA), um anomale Kommunikationsmuster zu erkennen.
- SOC und Echtzeit-Event-Systeme mit KI-Integration nutzen.
Priorität 3: Zero-Trust-Architektur beschleunigen
- Implementieren von Mikrosegmentierung, um die laterale Ausbreitung von Infektionen zu begrenzen.
- Kontinuierliche Authentifizierung einführen (nicht nur beim Login).
- Least-Privilege-Prinzip konsequent anwenden.
Priorität 4: Notfallpläne für KI-Bedrohungen aktualisieren
- Incident-Response-Vorbereitungen für KI-Würmer integrieren: Isolierung infizierter Systeme, forensische Analyse, Kommunikationsprotokolle.
- Offline-Backups für kritische Systeme sicherstellen (3-2-1-Regel: 3 Kopien, 2 Medien, 1 extern).
SOC: Operative Transformation zur verhaltensbasierten Erkennung
Priorität 1: Verhaltensbasierte Erkennungssysteme einführen
- UEBA-Tools für Benutzer und Systeme implementieren.
- Endpoint Detection and Response (EDR) auf allen kritischen Systemen einsetzen.
- Baselines für «normales» Verhalten entwickeln, um Abweichungen schnell zu erkennen.
Priorität 2: Automatisierte Response implementieren
- Plattformen zur Automatisierung von Reaktionen nutzen.
- Automatische Netzwerk-Isolierung über Network Access Control (NAC) konfigurieren, wenn verdächtige Aktivitäten erkannt werden.
Priorität 3: Threat Hunting mit KI-Unterstützung
- Proaktives Threat Hunting durchführen, das Indikatoren von Kompromittierung (IoCs) mit Verhaltensmustern korreliert.
- Deception-Technologien (Illusive Networks) einsetzen, um Angreifer in Fallen zu locken.
CSIRT: Schnelle Eindämmung und forensische Vorbereitung
Priorität 1: KI-Wurm-Checklisten und Playbooks entwickeln
- Eskalationspfade und Entscheidungsprozesse für Ausbruchsereignisse definieren.
- Netzwerk-Isolierungsszenarien planen: Welche Segmente können schnell getrennt werden.
Priorität 2: Forensik-Tools und Prozesse vorbereiten
- Memory-Forensik-Tools zur Analyse kompromittierter Systeme nutzen – das CSIRT hilft.
- Prozesse für schnelle Log-Analyse und Timeline-Rekonstruktion etablieren.
Priorität 3: Externe Koordination
- Kontakte zu relevanten Unterstützern (SOC; CSIRT; Cyber Versicherung) und Behörden (NCSC / BACS; BSI in Deutschland; CERT-Bund, lokale CERTs) definieren.
- Krisenkommunikations-Vorlagen für den Fall öffentlicher Kommunikation vorbereiten.
Unternehmen und KMUs: Operative Hygiene und Awareness
Grundlegende Massnahmen mit sofortiger Wirkung
- Patch-Management automatisieren: Regelmässige, getestete Updates für alle Systeme
- Multi-Faktor-Authentifizierung auf allen kritischen Systemen aktivieren
- Regelmässige, getestete Backups durchführen (3-2-1-Regel)
- Mitarbeitende-Schulungen durchführen zu KI-generierten Phishing-Angriffen
Externe Expertise nutzen
- Managed Security Services (MSSP) für 24/7-Monitoring evaluieren
- Regelmässige Penetrationstests mit externe Experten durchführen
- Threat Intelligence Feeds abonnieren (Anomali Threat Intelligence, ThreatConnect)
- Cyber-Versicherung prüfen: Deckt diese KI-basierte Angriffe ab?
Verhaltensbasierte Erkennung, Zero Trust, Segmentierung und eingespielte Incident Response schaffen die nötige Grundlage, um autonome Angriffsmuster früh einzuordnen und gezielt einzudämmen.
Jetzt ist der richtige Zeitpunkt, Abläufe von der Erkennung bis zur Wiederherstellung auf adaptive KI-Angriffe auszurichten und in Ihrer Sicherheitsarchitektur klar zu verankern.
Risikodifferenzierung nach Organisationstyp
Das Risiko durch KI-Würmer variiert erheblich je nach Unternehmensprofil.
KI-Würmer zwischen Compliance und geopolitischem Risiko
Europa: Unternehmen müssen NIS2-Anforderungen erfüllen, die Incident Response in kritischen Sektoren vorschreiben. Eine KI-Wurm-Infektion könnte zu regulatorischen Bussgeldern führen.
Kritische Infrastrukturen sind besonders exponiert (Energie, Wasser, Verkehr, Gesundheit): Ein erfolgreicher Angriff könnte öffentliche Dienste beeinträchtigen.
Geopolitische Dimension: Staaten könnten KI-Würmer als Cyberwaffen einsetzen. Dies macht Defensive-Massnahmen zu einer Frage der nationalen Sicherheit.
Q&As: Häufig gestellte Fragen
F: Kann dieser Wurm mein System infizieren?
A: Der akademische Prototyp ist aktuell nicht öffentlich verfügbar. Die Bedrohung liegt darin, dass ähnliche Techniken von Angreifern repliziert werden könnten. Dies erfordert erhebliche KI- und Sicherheits-Expertise. Organisationen mit modernen Defensive-Massnahmen (EDR, Segmentierung, UEBA) sind besser geschützt als solche mit minimaler Überwachung.
F: Sind meine Backups sicher?
A: Nur wenn sie offline sind. Backups, die mit dem Produktivnetzwerk verbunden sind oder remote zugänglich sind, könnten auch infiziert werden. Die 3-2-1-Regel (3 Kopien, 2 Medientypen, 1 extern/offline) bietet Schutz.
F: Belegt der OpenAI-Hugging-Face-Vorfall vom Juli 2026 die KI-Wurm-Bedrohung?
A: Der Vorfall bestätigt autonome KI-Angriffsfähigkeiten in kontrollierten Bedingungen, ist jedoch kein KI-Wurm im klassischen Sinne: Es fehlte die selbstständige Replikation über Netzwerke. Er demonstriert empirisch das Ausbrechen aus Sandboxes, Zero-Day-Exploitation und massenhafte autonome Aktionen (17’000+) ohne menschliche Steuerung. Für Praktiker bedeutet das: Die in diesem Artikel beschriebenen Abwehrmassnahmen sind ab sofort nicht mehr nur vorsorglich, sondern reaktiv notwendig.
F: Wie schnell muss ich handeln?
A: Sofort für grundlegende Massnahmen (Patch-Management, MFA, Backups). Für umfassendere Transformationen (UEBA, Zero-Trust) sollte ein 6-12-Monats-Plan etabliert werden.
Aktuelle Entwicklung: Der Hugging-Face-Vorfall (Juli 2026)
Am 22. Juli 2026 bestätigten OpenAI und Hugging Face einen Vorfall, der als Zäsur für die KI-Sicherheitsforschung gilt: Zwei KI-Modelle, das öffentliche GPT-5.6 Sol sowie ein noch unveröffentlichtes Vorabmodell, brachen während einer internen Sicherheitsevaluation eigenständig aus einer isolierten Sandbox-Umgebung aus und griffen die Produktionsinfrastruktur der Open-Source-KI-Plattform Hugging Face an.
Technische Details: Wie die KI-Modelle die Sandbox überwanden
Getestet wurden die Modelle auf dem ExploitGym-Benchmark, einer öffentlichen Vergleichsplattform für Hacking-Fähigkeiten. Zu Testzwecken wurden die üblichen Sicherheitsfilter deaktiviert. Die Modelle identifizierten, dass Hugging Face die Lösungsschlüssel für den Benchmark in seiner Datenbank speicherte, und nutzten eine Zero-Day-Schwachstelle in einem Cache-Proxy aus, um sich eigenständig Internetzugang zu verschaffen.
Im Verlauf des Angriffs wurden gestohlene Zugangsdaten eingesetzt und insgesamt mehr als 17’000+ autonome Aktionen ausgeführt. Hugging Face hatte den Einbruch parallel zur laufenden OpenAI-Evaluation entdeckt. Für die forensische Analyse war das Team auf das chinesische Open-Source-Modell GLM 5.2 von Z.ai angewiesen, da ein führendes US-amerikanisches Modell die Kooperation bei der Untersuchung verweigerte; eine unerwartete Einschränkung, die neue Abhängigkeiten in der Incident Response aufzeigt.
Der Vorfall ruft Behörden und Industrie auf den Plan
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) wertet den Vorfall als Beginn einer neuen Zeitrechnung für die Cybersicherheit. Die Behörde fordert Softwarehersteller auf, KI-Agenten klare Grenzen zu setzen: strikte Zugriffsrechtsbeschränkung, Netzwerktrennung und robuste Prüfmechanismen.
Auf EU-Ebene wiesen Parlamentarier darauf hin, dass der Vorfall gemäss der EU-KI-Verordnung (AI Act) meldepflichtig sei. Verschiedene Fraktionen forderten verbindliche Sicherheitsregeln für autonome KI-Agenten sowie eine Stärkung der technologischen Souveränität Europas.
Vom Einzelfall zur strategischen Konsequenz
Der OpenAI-Hugging-Face-Vorfall ist kein KI-Wurm im Sinne der Toronto-Forschung – er entstand nicht durch autonome Replikation über Netzwerke. Er demonstriert jedoch empirisch erstmals mehrere der im vorliegenden Artikel beschriebenen Risikofaktoren: autonomes Ausbrechen aus einer isolierten Umgebung, Ausnutzung unbekannter Zero-Day-Schwachstellen, Missbrauch gestohlener Zugangsdaten und das vollständige Fehlen menschlicher Intervention im Angriffsverlauf.
Für CISOs, SOCs und CSIRTs bedeutet dies: Die im Theorieteil beschriebene Reifung autonomer Angriffsfähigkeiten ist nicht mehr rein spekulativ. Die empfohlenen Massnahmen – Zero-Trust-Architektur, Netzwerksegmentierung, verhaltensbasierte Anomalie Erkennung und «KI-Wurm»-Checklisten – gewinnen durch diesen Vorfall an dringlicher Aktualität.
Fazit: Vorbereitung beginnt vor dem ersten KI-Wurm
Für CISOs, SOCs und CSIRTs entsteht daraus keine akute Krisenlage, jedoch ein klarer Auftrag zur Vorbereitung. Die Forschung aus Toronto zeigt, wie adaptive Malware künftig Schwachstellen identifizieren, Angriffswege verändern und vorhandene Ressourcen für ihre Ausbreitung nutzen könnte. Der Vorfall rund um OpenAI und Hugging Face macht zugleich sichtbar, dass autonome Angriffsschritte bereits heute technisch möglich sind.
Entscheidend ist deshalb, bestehende Sicherheitsstrukturen auf diese Entwicklung auszurichten. Dazu gehören insbesondere:
- Verhaltensbasierte Erkennung (nicht nur Signaturen)
- Zero-Trust-Architekturen und Netzwerk-Segmentierung
- Eingespielte Incident-Response-Prozesse für autonome Angriffsmuster
- Kulturelle Veränderung, die neue KI-Risiken früh einordnet und regelmässig prüft
Wer diese Grundlagen heute stärkt, gewinnt Zeit, Übersicht und Handlungssicherheit. Genau darin liegt der wichtigste Vorteil: Organisationen, die jetzt handeln, werden in den kommenden Jahren widerstandsfähiger gegen die nächste Generation von Cyberbedrohungen sein.
Bleiben Sie über aktuelle Entwicklungen informiert. Unsere Blog-Updates liefern regelmässig Einblicke in neue Bedrohungen, Sicherheitsrisiken und Trends der Cybersecurity.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()

Extreme Platform ONE: Netzwerkmanagement einfach und smart
Die wachsende Komplexität moderner Unternehmensnetzwerke stellt IT-Teams vor eine zentrale Herausforderung: Sie müssen immer mehr Daten, Abhängigkeiten und Tools beherrschen – häufig ohne zusätzliche Ressourcen. Genau hier entsteht eine der zentralen Herausforderungen im Netzwerkmanagement. Viele Organisationen betreiben historisch gewachsene Infrastrukturen mit separaten Management-Systemen für LAN, WLAN, WAN, Fabric, Security, Identity, Tickets und Monitoring. Störungen lassen sich zwar erkennen, aber die eigentliche Ursache liegt oft verborgen zwischen Telemetrie, Logs, Konfigurationen, Benutzerkontext, Policies und Applikationsdaten. Das kostet Zeit, bindet Spezialist:innen und erschwert eine proaktive Steuerung.
Warum klassisches Netzwerkmanagement an Grenzen stösst
In der Praxis sehen wir immer wieder dieselben Muster: Ein Benutzer meldet schlechte Performance. Das Monitoring zeigt erhöhte Latenzen. Im WLAN-Controller erscheinen Auffälligkeiten. Im Ticketing-System wurde kurz zuvor ein Change erfasst. Gleichzeitig laufen neue Applikationen über das WAN, während Security-Policies angepasst wurden. Jede Information ist für sich relevant – aber erst im Zusammenhang entsteht ein verwertbares Bild.
Klassische Tools liefern dafür oft zu viele Einzelsignale und zu wenig Kontext. Die Folge sind engere Analysezeiten, manuelle Korrelation, Tool-Wechsel und eine starke Abhängigkeit von erfahrenen Netzwerk- und Security-Spezialist:innen. Hinzu kommt: Je stärker Netzwerk und Security zusammenwachsen, desto wichtiger wird eine gemeinsame Sicht für NetOps, SecOps, Helpdesk und Architekturteams.
Extreme Platform ONE: ein Intelligence-Layer für Netzwerk und Security
Extreme Networks adressiert diese Entwicklung mit Extreme Platform ONE. Die Plattform führt Netzwerk, Sicherheit, Daten, Analysen und KI in einer einheitlichen Umgebung zusammen. Dabei geht es nicht einfach um eine weitere Management-Konsole, sondern um einen digitalen Intelligence-Layer, der Daten konsolidiert, Zusammenhänge erkennt und operative Entscheidungen unterstützt.
Die Plattform verbindet Cloud-natives Management, Automatisierung, Unified Data & Telemetry, offene Integrationen sowie KI-gestützte Funktionen. Dadurch erhalten Teams eine übergreifende Sicht auf Netzwerkzustand, Benutzer, Geräte, Applikationen, Standorte, Policies und Ereignisse. Statt einzelne Symptome isoliert zu betrachten, kann die Plattform Abhängigkeiten sichtbar machen – etwa zwischen einer Performance-Störung, einer Policy-Änderung, einem betroffenen Access Point, einem bestimmten Gerätetyp oder einer auffälligen Applikation.
KI, die den Betrieb unterstützt – nicht ersetzt
Ein zentraler Mehrwert von Extreme Platform ONE liegt im KI-gestützten Betrieb. Die Plattform nutzt Machine Learning, generative KI und agentenbasierte Ansätze, um Muster zu erkennen, Anomalien zu bewerten und Handlungsempfehlungen abzuleiten. Damit wird KI nicht als isoliertes Zusatzmodul verstanden, sondern als Bestandteil der Workflows.
Für Netzwerk-Teams kann das konkret bedeuten: Auffälligkeiten werden schneller eingeordnet, Root-Cause-Analysen werden unterstützt, Konfigurations- oder Policy-Probleme werden verständlich erklärt und mögliche nächste Schritte werden vorgeschlagen. Operator:innen können Fragen in natürlicher Sprache stellen – zum Beispiel, welche Standorte in den letzten 24 Stunden die meisten WLAN-Probleme hatten, welche Applikationen aktuell die höchste WAN-Last verursachen oder ob es Hinweise auf ungewöhnliches Geräteverhalten gibt.
Das reduziert die Einstiegshürde für weniger erfahrene Mitarbeitende und entlastet Senior Engineers bei wiederkehrenden Analysen. Gleichzeitig bleibt der Mensch in der Kontrolle. Empfehlungen können geprüft, angepasst und freigegeben werden. Gerade für regulierte Unternehmen ist dieser Ansatz entscheidend: KI soll Transparenz schaffen, Prozesse beschleunigen und Qualität verbessern – aber nicht unkontrolliert automatisieren.
Von reaktiver Fehlerbehebung zu proaktiver Optimierung
Der eigentliche Fortschritt liegt nicht nur darin, Störungen schneller zu beheben. Entscheidend ist der Schritt zu einem proaktiven Netzwerkbetrieb. Wenn Live-Daten, historische Telemetrie, Metadaten und Kontextinformationen zusammengeführt werden, lassen sich Entwicklungen früher erkennen: steigende Auslastung an bestimmten Standorten, wiederkehrende Konfigurationsfehler, Policy-Missmatches, auffällige Clients oder sich verschlechternde Servicequalität.
Damit wird das Netzwerk nicht erst dann sichtbar, wenn ein Incident entsteht. Es entwickelt sich zu einer Datenbasis, auf der Betrieb, Security und Architektur fundiertere Entscheidungen treffen können. Für Unternehmen mit verteilten Standorten, hybriden Infrastrukturen und hohen Verfügbarkeitsanforderungen ist dies ein wesentlicher Vorteil.
Integration in bestehende IT- und Security-Ökosysteme
Ein weiterer wichtiger Punkt ist die Einbettung in bestehende Umgebungen. Extreme Platform ONE ist darauf ausgelegt, nicht isoliert betrieben zu werden. Über APIs und Integrationen kann die Plattform mit ITSM-, SIEM-/SOAR-, Identity- und Cloud-Umgebungen zusammenspielen. Dadurch lassen sich Netzwerkereignisse mit Changes, Security-Incidents, Benutzeridentitäten oder Compliance-Anforderungen korrelieren.
Aus Sicht von InfoGuard ist genau diese Verbindung zentral. Netzwerkmanagement darf nicht losgelöst von Security Operations, Zero Trust, Identity, Cloud und Governance betrachtet werden. Der Mehrwert entsteht dort, wo technische Transparenz in belastbare Betriebs- und Sicherheitsprozesse überführt wird.
Warum sich Unternehmen jetzt mit Extreme Platform ONE beschäftigen sollten
Viele IT-Organisationen stehen vor derselben Aufgabe: Sie müssen komplexere Netzwerke betreiben, Risiken reduzieren, Automatisierung sinnvoll nutzen und gleichzeitig mit knappen Ressourcen umgehen. Extreme Platform ONE bietet dafür einen modernen Ansatz: weniger Tool-Silos, mehr Kontext, KI-gestützte Analysen, nachvollziehbare Empfehlungen und eine Plattform, die NetOps und SecOps näher zusammenbringt.
Für bestehende Extreme-Kunden ist die Plattform besonders interessant, weil sie vorhandene Technologien und Telemetriedaten stärker nutzbar macht. Für Unternehmen, die ihre Netzwerk- und Security-Architektur strategisch weiterentwickeln möchten, bietet sie einen konkreten Einstieg in KI-gestütztes Network Operations Management.
Hands-on Workshop: Extreme Platform ONE live erleben
Theorie ist wichtig. Entscheidend ist jedoch, wie sich eine Plattform im konkreten Betrieb anfühlt. Deshalb laden wir Sie zu unserem Extreme Hands-on Workshop am 20. August bei InfoGuard ein.
Im Workshop erleben Sie aktuelle Extreme-Technologien und Plattformansätze direkt in der Praxis. Gemeinsam mit den Expert:innen von InfoGuard und Extreme Networks können Sie typische Konfigurations-, Betriebs- und Troubleshooting-Szenarien durchspielen, Fragen aus Ihrer eigenen Umgebung einbringen und diskutieren, wie Extreme Platform ONE in Ihre Netzwerk- und Security-Architektur integriert werden kann.
Viele dieser Fragestellungen haben wir bereits in unserem vergangenen Webinar zu Extreme Platform ONE im Detail beleuchtet – inklusive Live-Demos und konkreten Use Cases. Die Aufzeichnung steht Ihnen On-Demand zur Verfügung, sodass Sie sich vorab einen fundierten Überblick verschaffen können.
Nutzen Sie die Gelegenheit, die Möglichkeiten von KI-gestütztem Netzwerkmanagement live kennenzulernen – und zu beurteilen, wo Platform ONE in Ihrer Organisation den grössten Nutzen stiften kann.
Jetzt Webinar-Aufzeichnung ansehen und für den Extreme Hands-on Workshop vom 20. August anmelden.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()

ISG und OT-Sicherheit: Neue Anforderungen für KRITIS
Mit dem Inkrafttreten des Informationssicherheitsgesetzes (ISG) gelten für Betreiber kritischer Infrastrukturen (KRITIS) neue Anforderungen an die Cybersicherheit. Neben Meldepflichten und klaren Governance-Vorgaben rückt insbesondere die Sicherheit von Operational Technology (OT) in den Fokus.
Denn durch die zunehmende Vernetzung von IT- und OT-Systemen entstehen neue Angriffsflächen: Bereits 80 % der Schweizer KRITIS-Betreiber berichten von Cybervorfällen in OT-Umgebungen, die zu Produktionsausfällen oder Datendiebstahl geführt haben. Unternehmen sollten daher ihre OT-Sicherheitsstrategie gezielt an die neuen gesetzlichen Vorgaben anpassen.
ISG-Anforderungen für OT-Verantwortliche
Das Schweizer Informationssicherheitsgesetz (ISG) definiert klare Anforderungen an Betreiber kritischer Infrastrukturen, insbesondere im Bereich der Operational Technology (OT).
Die zentralen Pflichten umfassen:
1. Meldepflicht bei Cybervorfällen (ISG Art. 73a-74f)
- Vorfälle mit erheblicher Auswirkung auf die Versorgungssicherheit oder öffentliche Sicherheit müssen unverzüglich (in der Regel innerhalb von 24-Stunden) an das Bundesamt für Cybersicherheit (BACS) gemeldet werden.
- Betroffen sind OT-Systeme, die für die Aufrechterhaltung kritischer Dienstleistungen (z.B. Energie, Verkehr, Wasser, Abwasser, Gesundheit) wichtig sind.
- Die Meldung erfolgt über das Meldesystem des BACS und muss technische Details, betroffene Systeme und Massnahmen enthalten.
2. Nachweis von Schutzmassnahmen (ISG Art. 64)
Betreiber müssen technische und organisatorische Schutzmassnahmen dokumentieren, um die Verfügbarkeit, Integrität und Vertraulichkeit von OT-Systemen zu gewährleisten. Konkrete Massnahmen (gemäss ISG und internationaler Standards wie ISA/IEC 62443):
- Netzwerksegmentierung (Isolation von OT- und IT-Systemen).
- Regelmässige Risikobewertungen (mindestens jährlich).
- Notfall- und Wiederanlaufpläne (inkl. Tests und Aktualisierungen).
- Zugangskontrollen (z.B. Multi-Faktor-Authentifizierung für kritische Systeme).
- Schulungen und Sensibilisierungsmassnahmen für Mitarbeitende.
3. Zusammenarbeit mit dem BACS (ISG Art. 15)
Betreiber sind verpflichtet, aktiv mit dem BACS zusammenzuarbeiten, insbesondere bei:
- Risikoanalysen (z.B. im Rahmen der nationalen Cybersicherheitsstrategie).
- Vorfalls-Untersuchungen (Forensik, Ursachenanalyse).
«Betreiber kritischer Infrastrukturen müssen Cybervorfälle, die die Versorgungssicherheit oder öffentliche Sicherheit gefährden, unverzüglich (in der Regel innerhalb von 24-Stunden) dem BACS melden und nachweisen, dass sie angemessene Schutzmassnahmen ergreifen.»
OT-Systeme im Fokus des ISG
OT-Systeme bilden das Rückgrat kritischer Infrastrukturen. Für ISG-konforme Strategien ist eine präzise Identifikation und Klassifizierung aller relevanten OT-Komponenten notwendig. Eine Schutzbedarfsanalyse hinsichtlich Verfügbarkeit, Integrität und Vertraulichkeit sowie die Berücksichtigung von IT-/OT-Abhängigkeiten ermöglichen eine gezielte Risikopriorisierung und die Ableitung regulatorisch relevanter Massnahmen.
Gründe, warum das ISG auch explizit OT adressiert:
- Durch die zunehmende Vernetzung von Steuerungssystemen mit der Unternehmens-IT entstehen neue Angriffsvektoren (z. B. Ransomware, die von der IT in die OT übergreift).
- Die IT/OT-Konvergenz erfordert Sicherheitsansätze wie Zero Trust, um laterale Bewegungen von Angreifern zwischen IT- und OT-Netzen wirksam zu verhindern.
- Zunehmende Angriffe auf OT: Laut BACS haben sich Cyberangriffe auf Schweizer Industrieanlagen seit 2022 verdoppelt – mit Fokus auf Energieversorger und Finanzinfrastrukturen.
- Die Abhängigkeit von Lieferketten und Drittanbietern (z. B. Wartungsfirmen, Cloud-Dienste) stellt ein häufiges Einfallstor dar – das ISG fordert daher entsprechende vertragliche Sicherheitsklauseln.
ISG: Sofortmassnahmen für OT-Verantwortliche
Das ISG verlangt kurzfristige, risikobasierte Eingriffe, um akute Bedrohungen in OT-Umgebungen zu reduzieren. Dazu gehören Zugangskontrollen, Patch-Management, Netzwerksegmentierung und Monitoring. Diese Massnahmen sichern die Compliance und gewährleisten die operative Stabilität der OT-Systeme in der unmittelbaren Handlungsphase.
1. Asset-Discovery inkl. OT/IT-Schnittstellen
- Passive Netzwerkanalyse zur Identifikation aller OT-Assets – einschliesslich Legacy-SPS und bislang unbekannter Verbindungen.
- Dokumentation der Schnittstellen zu IT-Systemen (z.B. Fernwartung, ERP-Anbindungen).
2. Notfall-Meldeweg zum BACS definieren (24-Stunden-Frist!)
- Klare Eskalationspfade festlegen. Wer meldet wann an das BACS?
- Vorlagen für Meldungen vorbereiten.
- Testmeldung durchführen, um den Prozess zu validieren.
3. Verantwortlichkeiten auf Geschäftsführungsebene verankern.
- CISO oder OT-Sicherheitsbeauftragten benennen.
- Regelmässige Berichte an die Geschäftsleitung (z.B. quartalsweise Risikostatus).
Mehr zu OT Security ServicesTechnik & Prozesse für OT-Sicherheit nach ISG
Die ISG-Konformität erfordert das Zusammenspiel technischer und organisatorischer Massnahmen. Kontinuierliches Monitoring, Incident-Response- und Wiederanlaufpläne, Backup-Strategien sowie klare Verantwortlichkeiten und Schulungen stellen sicher, dass OT-Systeme dauerhaft geschützt sind und die Audit-Readiness jederzeit nachgewiesen werden kann.
Praxisnahe Massnahmen für verbesserte OT-Sicherheit sind:
1. Segmentierung & Netzwerkzugangskontrolle
- Umsetzung eines Zonenmodells nach ISA/IEC 62443:
– Produktionszone (kritische Steuerungen)
– Wartungszone (Fernzugriffe, Updates)
– Externe Zone (Lieferanten, Cloud-Dienste)
- Einsatz von Firewalls mit OT-spezifischen Regeln (z. B. Modbus-/DNP3-Filterung).
- Strikte Netzwerksegmentierung zwischen IT- und OT-Umgebungen sowie innerhalb der OT-Zonen.
2. Resilienz & Wiederanlauf
- Backup-Strategie für OT-Systeme (inkl. Offline-Backups z.B. für SPS-Konfigurationen).
- Wiederanlaufpläne für kritische Prozesse (z.B. Stromversorgung, Zahlungsabwicklung).
- Regelmässige Tests (mindestens einmal jährlich).
3. Einbindung externer Dienstleister
- Aufnahme von Security-Klauseln in Verträge (z. B. Meldepflichten bei Vorfällen, Audit-Rechte).
- Bewertung von Lieferanten nach anerkannten Sicherheitsstandards (z. B. ISO/IEC 27001).
OT-Security: Compliance und Reporting nach ISG
Für ISG-konforme OT- und IT-Sicherheitsstrategien ist die Dokumentation der Massnahmen und Kontrollen unverzichtbar. Compliance-Nachweise ermöglichen es, regulatorische Anforderungen gegenüber Aufsichtsbehörden oder Auditoren transparent darzustellen.
Ein strukturiertes Reporting unterstützt zudem das Management bei der strategischen Steuerung der Informationssicherheit, erlaubt die frühzeitige Identifikation von Schwachstellen und stellt sicher, dass Audit-Readiness kontinuierlich gewährleistet ist.
Systematische Dokumentation der Tätigkeiten
- Dokumentation von Risikobewertungen auf Basis der ISA/IEC 62443-Methodik, einschliesslich der identifizierten Risiken und der daraus abgeleiteten Schutzmassnahmen.
- Lückenlose Erfassung aller Änderungen an OT-Systemen – etwa Firewall-Regeln oder Patches – inklusive Verantwortlichkeit, Zeitpunkt und Begründung.
- Regelmässige und protokollierte Incident-Response-Tests mit Dokumentation der Ergebnisse sowie abgeleiteten Massnahmen für den Ernstfall.
Im Falle eines meldepflichtigen Vorfalls müssen folgende Punkte klar kommuniziert werden:
- Betroffene Systeme und Angriffsvektoren. Welche Teile Ihrer Infrastruktur waren, betroffen, und wie erfolgte der Angriff.
- Auswirkungen des Vorfalls, z. B. Produktionsausfälle, Datenverlust oder Einschränkungen kritischer Prozesse.
- Ergriffene Massnahmen, wie der Vorfall eingedämmt wurde, welche Schritte zur Wiederherstellung eingeleitet wurden, und wie soll ein erneutes Auftreten verhindert werden.
Jährliche Risiko- und Compliance-Reviews – Kontinuierliche Verbesserung:
- Interne Audits mit Checklisten nach ISO/IEC 27001, um Schwachstellen zu identifizieren und zu beheben.
- Externe Prüfungen der OT-Sicherheit durch externe Stellen. Dokumentieren der Ergebnisse und Umsetzung der Massnahmen Empfehlungen.
Fazit: ISG stärkt OT-Sicherheit und Resilienz
Das Informationssicherheitsgesetz bietet die Chance,
- die Cyberresilienz von OT-Systemen zu erhöhen,
- Betriebsunterbrüche durch klare Prozesse zu minimieren,
- sowie Vertrauen bei Kunden, Partnern und Behörden zu stärken.
Das ISG schafft damit nicht nur regulatorische Klarheit, sondern setzt auch wichtige Impulse für den nachhaltigen Ausbau der OT-Sicherheit. Entscheidend ist dabei die konsequente Umsetzung der Anforderungen im operativen Betrieb, um Risiken frühzeitig zu erkennen und die Widerstandsfähigkeit kritischer Systeme dauerhaft zu erhöhen.
In der Praxis zeigt sich, dass insbesondere eine strukturierte Herangehensweise an Governance, Prozesse und technische Schutzmassnahmen den grössten Hebel für eine robuste OT-Resilienz bietet.
Gerne unterstützen wir Sie bei der ISG-Umsetzung und liefern Ihnen massgeschneiderte Empfehlungen für Ihre OT-Sicherheit. Kontaktieren Sie uns hierzu gerne und jederzeit!
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()

Cyberangriffe ohne Hollywood-Hacking: 350 analysierte Fälle. Drei Muster.
Cybersicherheit scheitert selten daran, dass irgendwo ein einzelnes Tool fehlt. Weitaus häufiger liegen die Ursachen in gewachsenen Strukturen, stillen Annahmen und blinden Flecken, die über Jahre niemand mehr hinterfragt. Warum Sichtbarkeit dabei entscheidend ist, haben wir in einem weiteren Beitrag zum Thema beleuchtet. Was im Alltag als logisch, effizient oder historisch gewachsen gilt, kann im Ernstfall zum Einfallstor für Angreifer werden. Drei Szenarien zeigen, wo Unternehmen besonders häufig angreifbar bleiben – und wie sich die grössten Risiken gezielt entschärfen lassen.
Szenario 1: Ransomware über VPN-Zugang und gestohlene Zugangsdaten
Ein Mitarbeitender verwendet dieselben Zugangsdaten über Jahre hinweg sowohl privat wie auch geschäftlich. Das Passwort im Geschäft wird gemäss den internen Richtlinien zwar regelmässig geändert, aber eigentlich ist die Basis des Passworts immer gleich, nur werden die Zahlen jeweils ein wenig geändert.
Für den Mitarbeitenden ist es üblich, dass er ab und zu von seinem privaten Computer die Geschäfts-E-Mails überprüft und aus Gründen der Bequemlichkeit, wird das Passwort im Browser gespeichert, damit er es nicht jedes Mal erneut abtippen muss. Der Mitarbeitende lädt sich aus Versehen aus dem Internet einen InfoStealer herunter und installiert diesen. Der InfoStealer ist Teil einer legitimen Software, welche der Mitarbeitende für private Zwecke nutzen möchte.
Völlig unbemerkt kann dieser InfoStealer erfolgreich ausgeführt werden, wodurch sämtliche gespeicherten Passwörter an Cyberkriminelle übermittelt werden. Welche diese Zugangsdaten für ein paar wenige Dollar auf Cybercrime-Marktplätzen zum Verkauf anbieten.
Ransomware-Affiliates sind auf Unternehmenszugänge angewiesen, und greifen hierfür gerne auf Cybercrime-Marktplätze zurück, wo sie bei der Durchsicht der neuesten Stealer Logs ein lohnenswertes Ziel identifizieren, nämlich den E-Mail-Zugriff auf ein bekanntes Unternehmen, welche zuvor auf dem privaten Gerät des Mitarbeitenden entwendet wurde.
Mit wenig Aufwand identifiziert der Angreifer, den VPN-Einstiegspunkt des Unternehmens und probiert die zuvor erlangten Zugangsdaten aus: Welch ein Wunder, es wird kein zweiter Faktor bei der Authentifizierung abgefragt und der Ransomware Affiliate hat sich den Zugang zu seinem nächsten Ransomware-Opfer mit wenig Aufwand gesichert.
Nach erfolgreicher Anmeldung findet der Angreifer:
- ein flaches Netzwerk ohne Segmentierung
- administrative Freigaben
- zentrale Dateiserver
- Backup-Systeme
- Hypervisor-Management
- weitere privilegierte Konten
Innerhalb weniger Stunden entwickelt sich aus einem einzelnen VPN-Login ein unternehmensweiter Ransomware-Vorfall.
3 zentrale Massnahmen gegen Ransomware-Vorfälle
- Identitäten härten
– MFA für sämtliche Remote-Zugänge
– Phishing-resistente MFA-Verfahren bevorzugen
– Conditional Access und risikobasierte Anmeldungen - Externe Angriffsfläche überwachen
– Sichtbarkeit über exponierte Unternehmenseinstiege
– Kontinuierliche Überwachung von Stealer Logs
– Kontinuierliches Vulnerability Management - Laterale Bewegung begrenzen
– Netzwerksegmentierung
– Trennung von Benutzer-, Server- und Managementzonen
– Separater Zugriff auf Hypervisoren und Backups
Szenario 2: Supply-Chain-Angriff durch kompromittierte Software
Ein Administrator kümmert sich um seine Serverlandschaft und möchte sämtliche Systeme auf den neusten Stand bringen. Hierzu lädt er sich direkt die notwendigen Updates aus dem Internet herunter, installiert diese und kümmert sich um den nächsten Server.
Auf der Suche nach aktuellen Security Patches landet er auf einer über Google-Ads beworbenen Webseite eines Threat Actors. Dort werden mehrere Business-Applikationen zum Download angeboten. Tatsächlich sind sie mit einer Remote-Management-Lösung gebündelt, die nach der Installation direkten Fernzugriff auf den Server ermöglicht.
Da die Installation durch einen autorisierten Administrator erfolgt, wirken viele Sicherheitskontrollen zunächst unauffällig:
- Die aktualisierte Software ist auf dem neusten Stand
- Die Antivirus-Software hat die legitime Remote-Management-Lösung nicht detektiert
- Der Proxyserver hat den Download ohne Hinweis zugelassen.
In zahlreichen aktuellen Kampagnen wurden genau solche Mechanismen genutzt:
- kompromittierte Open-Source-Komponenten
- kompromittierte Entwicklersoftware und Plugins
- infizierte Softwarepakete/Betriebssystem-Images
Das Gefährliche an dieser Art der Kompromittierung ist, dass der Angreifer einen privilegierten und persistenten Zugriff ins Unternehmen erhält. Je nach kompromittiertem System kann er auch direkt auf kritische Geschäftsdaten zugreifen und diese exfiltrieren. Weitere Angriffstechniken braucht es kaum und genau deshalb bleibt der Vorfall für das Security Monitoring oft lange unauffällig. Wird die Datenexfiltration erkannt, ist es unter realistischen Bedingungen meist bereits zu spät: Kritische Informationen haben das Unternehmen dann längst verlassen.
Solche Angriffsmuster beobachten wir sowohl bei Nation-State-Akteuren wie auch bei Initial-Access-Brokern und Ransomware-Gruppierungen. Sie nutzen diese Techniken zunehmend, weil sie effizient, schwer erkennbar und sehr wirkungsvoll sind.
4 zentrale Massnahmen gegen Supply-Chain-Angriffe
- Privilegierte Zugriffe reduzieren
– Least Privilege konsequent umsetzen
– Separate Administrationskonten
– Privileged Access Management - Software-Lieferkette absichern
– Herkunft von Software überprüfen
– Kritische Updates vor Rollout validieren
– Software Bill of Materials (SBOM) nutzen - Verhalten statt Signaturen überwachen
– EDR-Abdeckung auf allen kritischen Systemen
– Monitoring von Build-Servern
– Monitoring von Entwickler-Workstations
– Erkennung ungewöhnlicher Netzwerkkommunikation -
Kritische Systeme isolieren
– Segmentierung von Management- und Produktionssystemen
– Einschränkung direkter Internetzugriffe
– Kontrollierte Software-Verteilung
Bewerten Sie die relevanten Cyberrisiken für Ihr Unternehmen und priorisieren Sie die passenden Schutzmassnahmen. Das Whitepaper «InfoGuard Threat Intelligence Insights 2025» liefert dazu das Know-how für Ihren Realitätscheck.
Szenario 3: Ghost Sender – Wenn Konfigurationsfehler zum Sicherheitsrisiko werden
Beim Threat Hunting stösst das Analyseteam auf Anomalien in den E-Mail-Logs. Die Analyse zeigt mehrere ungewöhnliche E-Mail-Absenderadressen, über die Links zu unbekannten Webseiten an hochprivilegierte Konten versendet wurden.
Eine vertiefte Analyse der Logs zeigt zunächst ein irritierendes Bild: Die E-Mails scheinen aus der eigenen Organisation zu stammen. Der Verdacht einer Kompromittierung steht im Raum, entsprechend wird eine Taskforce einberufen, welche den Sachverhalt prüfen soll.
Die ersten Analysen zeigen keine Kompromittierung des on-prem Exchange Servers. Es wurden keine kompromittierten Endgeräte identifiziert und auch sonst gibt es keine verdächtigen Logins, welche den Sachverhalt erklären würden. Das Analyseteam stellt zudem fest, dass der Sachverhalt bereits seit einigen Monaten andauert. Zunächst fielen jedoch nur Testnachrichten, Fehlzustellungen und vereinzelte E-Mails auf, die nicht plausibel wirkten, aber nicht weiter untersucht wurden.
Die Taskforce bespricht die aktuellen Findings. Hinweise auf eine Kompromittierung gibt es nicht. Die E-Mail-Konfiguration wurde seit Jahren nicht verändert und scheint nicht manipuliert worden zu sein. Auch Hinweise auf die Kompromittierung eines Drittanbieters lässt sich nicht nachweisen. Dann formuliert jemand aus dem Team die Hypothese, dass das Email Security Gateway möglicherweise umgangen wurde.
Wie konnte diese E-Mail-Fehlkonfiguration entstehen?
Die Organisation betreibt eine moderne E-Mail-Sicherheitsarchitektur und hat vor Exchange Online ein etabliertes Secure E-Mail Gateway vorgeschaltet. Die Annahme des Unternehmens? Sämtliche E-Mails müssen diese Kontrollpunkte passieren. Genauso war es in der Architektur auch definiert.
Die Analyse zeigt jedoch, dass Exchange Online weiterhin direkte Zustellungen aus dem Internet zulässt. Der Gateway ist also vorhanden, die Sicherheitskontrollen für den definierten Mailfluss sind implementiert und auch die entsprechenden Prozesse sind korrekt etabliert. Doch zusätzlich existiert ein alternativer Pfad, der womöglich bei der Einführung notwendig war, aber in keinem Architekturdiagramm auftaucht und nie Teil des Bedrohungsmodells war. Diese Bedrohung hat nun einen Namen «Ghost Sender».
Welche Lehren lassen sich daraus ziehen?
Ghost Sender ist technisch betrachtet eine Fehlkonfiguration und organisatorisch ein blinder Fleck. In diesem Fall hat niemand fahrlässig gehandelt: Der Gateway ist korrekt installiert, die Umgebung korrekt betrieben, die Sicherheitsverantwortlichen haben ihre Aufgaben erfüllt. Doch ist die Architektur über die Jahre komplexer geworden.
Spamfilter wurden implementiert, E-Mail Archivierung integriert, diverse Partneranbindungen geschaffen, Cloud-Migrationen umgesetzt, Ausnahmeregeln definiert und temporäre Workarounds implementiert. Jede dieser Änderungen ist nachvollziehbar. Doch jede zusätzliche Komponente erhöht die Komplexität des Gesamtsystems und genau dort entstehen Risiken. Sicherheitsarchitekturen altern. Deshalb müssen sie regelmässig validiert und kritisch hinterfragt werden. Denn die gefährlichsten Schwachstellen sind nicht die, die man kennt, sondern jene von denen man überzeugt ist, dass sie gar nicht existieren können.
Die Komplexität ist nicht nur ein Problem bei der Erkennung solcher Schwachstellen, sondern auch in der Behebung davon. So konnte beispielsweise in der Praxis beobachtet werden, dass einige Unternehmen mehrere Wochen benötigten, um die Fehlkonfiguration zu beheben, während sie in dieser Zeit anfällig für entsprechende Phishingangriffe waren.
3 zentrale Massnahmen gegen Ghost Sender
- Konfigurationshygiene etablieren
– Regelmässige Überprüfung von SPF
– DKIM korrekt implementieren
– DMARC Enforcement aktivieren - Externe Sicht einnehmen
– Kontinuierliche Überwachung der eigenen Angriffsfläche
– Validierung von DNS- und Mail-Konfigurationen
– Regelmässige Exposure-Assessments - Prozesse für schnelle Reaktion schaffe
– Veranwortlichkeiten definieren
– Kritische Änderungen priorisieren
– Standardisierte Risikoanalysen etablieren
Das gemeinsame Angriffsmuster hinter allen drei Vorfällen
Auf den ersten Blick wirken diese Angriffe völlig unterschiedlich.
- Ransomware über VPN
- Supply-Chain-Kompromittierung
- Ghost-Sender-Fehlkonfiguration
Tatsächlich teilen sie dieselbe Ursache
Fehlende Transparenz über Risiken, die ausserhalb des direkten Blickfelds liegen.
Der VPN-Zugang ohne MFA war exponiert. Die Lieferkette wurde ungeprüft als vertrauenswürdig behandelt. Die Mail-Infrastruktur enthielt unbekannte Schwachstellen oder Fehlkonfigurationen. Keiner dieser Angriffe begann mit einem hochkomplexen technischen Exploit. Sie begannen mit einer Sicherheitslücke in der Sichtbarkeit, Kontrolle oder der Governance.
Cyberrisiken sehen, bevor sie zum Angriffspfad werden
Die entscheidende Frage lautet heute nicht mehr: «Haben wir genügend Security-Produkte?» Sondern: «Wissen wir, welche Risiken ausserhalb unseres aktuellen Sichtfelds existieren?» Wer seine Identitäten schützt, die Software-Lieferkette überwacht und externe Angriffsflächen kontinuierlich versteht, reduziert und nicht nur die Wahrscheinlichkeit erfolgreicher Cyberangriffe, sondern erkennt Bedrohungen deutlich früher.
Diese drei Beispiele zeigen dabei nur einen kleinen Ausschnitt aktueller Angriffsmuster.
In unserem aktuellen InfoGuard Threat Intelligence Whitepaper analysieren wir:
- die wichtigsten Angriffsvektoren des vergangenen Jahres
- aktuelle Entwicklungen im Bereich Ransomware, Supply Chain und Identity Attacks
- teilen konkrete Incident-Response-Erkenntnisse aus der Praxis
- und priorisierte Schutzmassnahmen für Unternehmen und Behörden
Nutzen Sie das kostenlose Whitepaper «InfoGuard Threat Intelligence Insights 2025» als Realitätscheck: Prüfen Sie, welche Angriffsmuster jetzt besonders relevant sind und welche Massnahmen für Ihre Organisation Priorität haben.
Sie möchten keine wichtigen Entwicklungen verpassen? Abonnieren Sie unsere Blog-Updates und profitieren Sie von regelmässigen Einblicken in aktuelle Bedrohungstrends, Sicherheitsrisiken und relevante Marktbewegungen.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()

AI Trust statt Bauchgefühl: Warum KI verifizierbare Trust-Architekturen braucht
Durch die wachsende Autonomie von KI-Systemen darf Vertrauen kein Bauchgefühl bleiben. Unternehmen müssen wissen, welche KI-Systeme aktiv sind, welche Rechte sie besitzen und ob ihre Ergebnisse nachvollziehbar bleiben. Klassische Security- und Governance-Modelle stossen hier an Grenzen. Sie wurden vor allem für Menschen, Geräte, Applikationen und bekannte Softwareprozesse entwickelt.
KI-Systeme verhalten sich jedoch dynamischer. Sie können Daten verarbeiten, Aktionen auslösen, externe Tools einbinden und über Systemgrenzen hinweg agieren. Unternehmen brauchen deshalb eine neue Vertrauensarchitektur: AI Trust. Gemeint ist ein Ansatz, der Identität, Berechtigungen, Integrität und Herkunft von KI-Systemen und KI-generierten Inhalten technisch überprüfbar macht.
Von Digital Trust zu AI Trust
Digital Trust basiert seit Jahren auf bewährten Prinzipien wie Public Key Infrastructure, Zertifikaten, DNS und Verschlüsselung. Diese Mechanismen sorgen dafür, dass digitale Kommunikation geschützt, Identitäten überprüft und Systeme authentifiziert werden können.
Mit KI erweitert sich dieser Vertrauensraum. Unternehmen müssen künftig nicht nur wissen, wer auf ein System zugreift, sondern auch:
- Welche KI-Agenten aktiv sind
- Welche Daten sie verarbeiten
- Welche Berechtigungen sie besitzen
- Ob ein Inhalt echt, verändert oder KI-generiert wurde
AI Trust überträgt bewährte Vertrauensmechanismen auf KI. Ziel ist es, KI-Agenten, Modelle und Inhalte nicht nur zu regulieren, sondern technisch kontrollierbar zu machen.
Shadow AI: Wenn KI der Governance davonläuft
Viele Unternehmen nutzen KI bereits produktiv – teils offiziell, teils informell. Besonders kritisch ist sogenannte Shadow AI: der Einsatz von KI-Tools oder Agenten ausserhalb freigegebener Prozesse.
Dadurch entstehen blinde Flecken. Sensible Daten können unkontrolliert verarbeitet werden. Agenten erhalten möglicherweise zu weitreichende Rechte. Und Security-Teams wissen nicht immer, welche KI-Systeme tatsächlich im Einsatz sind.
Für CISOs wird Shadow AI damit zum Transparenztest. Entscheidend sind fünf Fragen:
- Welche KI-Agenten werden im Unternehmen genutzt?
- Welche Daten fliessen an diese Systeme?
- Welche Agenten besitzen Zugriff auf interne Systeme?
- Können kompromittierte Agenten sofort gestoppt werden?
- Lässt sich ein Vorfall nachvollziehbar dokumentieren?
Die Antwort darauf kann nicht allein in Richtlinien liegen. KI-Governance muss technisch durchsetzbar werden.
Drei Bereiche, in denen Vertrauen neu gedacht werden muss
AI Trust betrifft vor allem drei Ebenen: Agenten, Modelle und Inhalte.
- Vertrauen in KI-Agenten – AI Agent Passport
KI-Agenten sind keine menschlichen Benutzer. Passwörter oder klassische Login-Prozesse greifen hier zu kurz. Agenten benötigen eindeutige, kurzlebige und überprüfbare Identitäten. So lässt sich kontrollieren, welche Aktionen sie ausführen dürfen, auf welche Daten sie zugreifen können und wann ein Zugriff beendet werden muss.
Ein Ansatz dafür ist der AI Agent Passport. Er verbindet die Identität eines Agenten kryptographisch mit seinen Berechtigungen. Damit wird nachvollziehbar, was ein Agent tun darf, in welcher Umgebung er aktiv ist und wer dafür verantwortlich ist. - Vertrauen in KI-Modelle – Confidential Computing
KI-Modelle werden zunehmend zu kritischen Unternehmensressourcen. Sie unterstützen Diagnosen, erkennen Betrug, automatisieren Compliance-Prozesse oder beeinflussen geschäftsrelevante Entscheidungen.
Deshalb müssen Unternehmen sicherstellen, dass Modelle nicht manipuliert, unerlaubt verändert oder in unsicheren Umgebungen ausgeführt werden. Dazu braucht es unter anderem kryptographisches Signieren, Integritätsprüfungen und nachvollziehbare Modellherkunft. Besonders relevant ist Confidential Computing. Dabei werden Modelle in geschützten Ausführungsumgebungen betrieben. So bleiben Daten und Modellinformationen auch während der Verarbeitung geschützt. - Vertrauen in KI-generierte Inhalte – C2PA
KI kann heute Texte, Bilder, Videos und strukturierte Daten in hoher Qualität erzeugen oder verändern. Für Unternehmen wird deshalb die Frage zentral: Woher stammt ein Inhalt? Wurde er verändert? Und kann seine Echtheit unabhängig geprüft werden? Metadaten oder Plattformhinweise reichen dafür nicht aus. Sie können entfernt oder verändert werden. Standards wie C2PA schaffen eine Grundlage, um digitale Inhalte mit signierten Herkunftsnachweisen zu versehen. So wird überprüfbar, wer einen Inhalt erstellt hat und ob er seitdem verändert wurde.
Identität, Kryptographie und DNS als Vertrauensanker
Eine tragfähige AI-Trust-Architektur braucht technische Kontrollpunkte. Dazu gehören DNS-basierte Richtlinien, kryptographische Identitäten, kurzlebige Credentials, Attestation und Integritätsnachweise.
Ein Beispiel: Bevor ein KI-Agent eine externe Verbindung aufbaut, kann geprüft werden, ob die Ziel-Domain erlaubt ist. Ist sie nicht freigegeben, wird die Verbindung blockiert, bevor Daten abfliessen oder unerlaubte Aktionen ausgelöst werden.
Solche Mechanismen machen aus abstrakter Governance konkrete Kontrolle. Unternehmen können festlegen, welche Agenten was tun dürfen – und diese Regeln technisch durchsetzen.
Von Transparenz zu Kontrolle: 5 Schritte für AI Trust
Am Anfang steht die Bestandesaufnahme. Unternehmen sollten erfassen, welche KI-Tools, Agenten und Modelle bereits genutzt werden und welche Datenflüsse damit verbunden sind.
Darauf aufbauend sollten sie definieren:
- Welche KI-Systeme erlaubt sind
- Welche Daten verarbeitet werden dürfen
- Welche Identitäten und Berechtigungen erforderlich sind
- Wie Modelle geschützt und überprüft werden
- Wie KI-generierte Inhalte gekennzeichnet und verifiziert werden können
So wird AI Trust zu einem praktischen Sicherheits- und Governance-Thema – nicht zu einem theoretischen Konzept.
DigiCert als Leader für Intelligent Trust
Moderne Ansätze für Digital Trust setzen genau hier an. DigiCert positioniert sich als globaler Leader für Intelligent Trust und erweitert bewährte Prinzipien wie PKI, DNS, Certificate Lifecycle Management, Attestation und kryptographische Identität auf die Anforderungen moderner KI-Umgebungen.
Die Plattform DigiCert ONE vereint zentrale Trust-Funktionen in einer integrierten Architektur und unterstützt Unternehmen dabei, digitale Vertrauensanker sichtbar, steuerbar und automatisierbar zu machen. Dazu gehören unter anderem PKI, DNS, Zertifikatsmanagement, Software Trust, Device Trust und Content Trust.
Für AI Trust entsteht daraus eine technische Grundlage, mit der Organisationen KI-Systeme nicht nur nutzen, sondern kontrolliert, nachvollziehbar und verantwortungsvoll betreiben können.
InfoGuard & DigiCert – Vertrauen für die nächste KI-Ära
Mit DigiCert erweitert InfoGuard bewährte Digital-Trust-Prinzipien auf die Anforderungen moderner KI-Umgebungen. Bereits beim automatisierten Zertifikatsmanagement zeigt sich, wie wichtig Transparenz, Automatisierung und Krypto-Agilität für stabile und sichere digitale Infrastrukturen sind. Im KI-Kontext gewinnen dieselben Prinzipien zusätzlich an Bedeutung: Identitäten müssen überprüfbar, Berechtigungen kontrollierbar und Integrität kontinuierlich nachweisbar sein.
So entsteht die Grundlage, um KI nicht nur produktiv einzusetzen, sondern sicher, nachvollziehbar und kontrollierbar zu betreiben. Erfahren Sie im Whitepaper, wie die «Trust Architecture for AI» von DigiCert Unternehmen dabei unterstützt, Vertrauen in KI-Systeme technisch überprüfbar zu machen.
InfoGuard begleitet Unternehmen, ihre AI Trust von Anfang an als Sicherheits- und Architekturthema zu denken – von Governance-Fragestellungen über technische Integration bis zur Absicherung von Identitäten, Daten, Cloud- und KI-Umgebungen. Unsere Expert:innen freuen sich auf den unverbindlichen Austausch!
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()

API-Security: So schützen Sie Schnittstellen effektiv vor KI-Angriffen
Wenn zentrale Schnittstellen zur Schwachstelle werden
Die Anzahl der API-Angriffe steigt signifikant. Der Einsatz von KI fungiert dabei als Beschleuniger für Angriffe und erschwert zugleich die Erkennung von Sicherheitslücken. Laut Akamais State of the Internet Report 2026 stieg die durchschnittliche Anzahl täglicher API-Angriffe pro Unternehmen von 121 (2024) auf 258 im Jahr 2025, was einem Anstieg von 113 % entspricht. Betroffen sind auch Finanzdienstleister, E-Commerce-Plattformen sowie KMU, die häufig veraltete oder undokumentierte APIs betreiben.
API-Security ist damit kein technisches Spezialthema mehr, sondern ein geschäftskritischer Faktor für Verfügbarkeit, Datenschutz und Compliance.
APIs verbinden zentrale Prozesse, Daten und Systeme, bei häufig fehlender Transparenz und Kontrolle. Genau daraus entstehen neue Angriffsflächen.
Drei Risikobereiche sind dabei besonders relevant: Shadow APIs, Business Logic Abuse und KI-gestützte Angriffe auf APIs.
Drei Risikobereiche, die API-Security unverzichtbar machen
1. Shadow APIs: Das unsichtbare Risik
Viele Unternehmen betreiben mehr APIs als dokumentiert. Undokumentierte oder vergessene Schnittstellen („Shadow APIs“) entziehen sich oft der Sicherheitsüberwachung und werden gezielt angegriffen. Die Folgen reichen von unkontrollierten Datenzugriffen und Compliance-Verstössen bis hin zu einer erheblich vergrösserten Angriffsfläche.
Handlungsempfehlungen:
- Regelmässige API-Discovery-Scans durchführen
- Ein zentrales API-Inventar mit klaren Verantwortlichkeiten etablieren
- APIs in regelmässige Sicherheitsprüfungen und Penetrationstests einbeziehen
Zentrale Erkenntnis für Unternehmen:
Fehlende API-Transparenz ist kein technisches Randproblem, sondern vor allem ein Governance-Thema. Was nicht bekannt ist, kann weder bewertet noch geschützt werden. Der erste Schritt wirksamer API-Security besteht deshalb darin, Transparenz über die eigene API-Landschaft zu schaffen.
2. Business Logic Abuse: Wenn legitime APIs missbraucht werden
Beim Business Logic Abuse greifen Angreifer nicht technische Schwachstellen an, sondern missbrauchen die Geschäftslogik einer API selbst. Typische Szenarien sind Preismanipulationen im E-Commerce durch manipulierte Rabattcodes, das Umgehen von Zahlungsprozessen durch veränderte Parameter, automatisiertes Daten-Scraping für Wettbewerbsanalysen oder Identitätsmissbrauch durch variierte Anfragen.
Handlungsempfehlungen:
- Validierung von API-Schemas und Geschäftsregeln
- Systematische Tests der Business Logic (inkl. Missbrauchsszenarien)
- Durchgängiges Rate Limiting und Throttling
Zentrale Erkenntnis für Unternehmen:
Business Logic Abuse ist primär ein Anwendungs- und Prozessrisiko. Angriffe erfolgen über legitime Funktionen, ohne dass klassische Schwachstellen notwendig sind. Entscheidend ist daher nicht nur die Absicherung der API, sondern das Verständnis und die kontinuierliche Überwachung der zugrunde liegenden Geschäftslogik.
3. KI-gestützte Angriffe auf APIs: Wenn Angriffe skalierbar und adaptiv werden
Künstliche Intelligenz verändert die Angriffslandschaft grundlegend. Angreifer setzen zunehmend KI-gestützte Tools ein, um Schwachstellen automatisiert zu identifizieren, Angriffe zu skalieren und ihr Verhalten dynamisch an legitimen API-Traffic anzupassen.
Dadurch steigt das Tempo der Angriffe, während ihre Erkennbarkeit sinkt. Klassische, regelbasierte Sicherheitsmechanismen stossen dabei zunehmend an ihre Grenzen.
Handlungsempfehlungen:
- Einsatz KI-basierter Anomalieerkennung
- Integration von API-Monitoring ins Security Operations Center (SOC)
- Stärkung von Credential- und Token-Sicherheit
Zentrale Erkenntnis für Unternehmen:
KI-gestützte Angriffe stellen ein dynamisches Bedrohungsrisiko dar. Sie erhöhen Geschwindigkeit, Skalierung und Tarnfähigkeit von Angriffen erheblich. Wirksam begegnen lässt sich dieser Entwicklung nur durch eine innovative Sicherheitsarchitektur sowie verhaltensbasierte Erkennung und kontinuierliches Monitoring von API-Aktivitäten.
Security Architecture & Design entdecken
API-Sicherheit: Schritt-für-Schritt Anleitung
Mit zunehmender Komplexität moderner API-Landschaften reicht punktuelle Absicherung nicht mehr aus. Professionelle API-Security ist weit mehr als die reine Absicherung einzelner Schnittstellen. Sie muss entlang des gesamten API-Lifecycles gedacht werden. Somit ist sie kein Einzelprojekt, sondern ein kontinuierlicher Prozess, der Technologie, Entwicklung und Governance verbindet.
Der folgende Leitfaden zeigt, wie Unternehmen ihre API-Sicherheit strukturiert verbessern und Risiken nachhaltig reduzieren können.
1. API-Discovery & Inventory
Transparenz ist die Grundlage jeder wirksamen API-Sicherheit. Nur wer alle APIs kennt, kann sie schützen.
- Automatisierte Erkennung aller APIs
- Aufbau eines zentralen, gepflegten API-Inventars
- Klare Verantwortlichkeiten für jede API (z. B. Product Owner)
2. Moderne Authentifizierung & Autorisierung
Veraltete Authentifizierungsverfahren erhöhen das Risiko unnötig. Moderne Standards schaffen hier deutlich mehr Sicherheit und Kontrolle.
- Ablösung einfacher API-Keys und Basic Auth
- Einsatz von OAuth 2.0 und OpenID Connect
- Granulare Zugriffskontrollen (ABAC) auf Objektebene
- Vermeidung von Broken Object Level Authorization (BOLA)
3. Schutz durch Rate Limiting & Schema Validation
Viele Angriffe auf APIs sind automatisiert – und damit hochskalierbar.
Entsprechende Schutzmechanismen reduzieren diese Risiken deutlich.
- Rate Limiting für alle APIs aktivieren (z. B. 100 Requests/Minute pro Benutzer)
- Nutzung von OpenAPI-Spezifikationen als „Positive Security Model“
- Integration von Schema-Validierung in CI/CD-Pipelines
4. KI-basierte Abwehr & SOC-Integration
Die Angriffsgeschwindigkeit steigt – klassische Reaktionsmodelle reichen oft nicht mehr aus. Daher gewinnen automatisierte Erkennung und SOC-Integration an Bedeutung.
- API-spezifische Use Cases im SOC etablieren
- Dedizierte Alerts für API-Missbrauch definieren
- Security-Teams im Umgang mit KI-gestützten Angriffen schulen
5. DevSecOps & automatisierte Compliance
API-Security muss früh im Entwicklungsprozess verankert sein – nicht erst im Betrieb.
- Security-Kontrollen früh in der Entwicklung integrieren
- Automatisierte Compliance-Checks implementieren
- Entwickler gezielt in API-Security schulen
Tokens und Verifiable Credentials als strategische Ergänzung
Die Kombination aus Tokens und Verifiable Credentials (VCs) entwickelt sich zunehmend zu einer wichtigen Erweiterung moderner API-Sicherheitsarchitekturen.
Während Tokens (z. B. JWT) für die Echtzeit-Authentifizierung und -Autorisierung von API-Zugriffen eingesetzt werden, ermöglichen VCs die Verifikation von Identitäts- oder Qualifikationsnachweisen.
Zusammenspiel in der Praxis:
- API-Keys durch Token-basierte Verfahren (z. B. JWT) ersetzen
- Verifiable Credentials für Identitäts- und Mitarbeiternachweise nutzen
- API-Gateways zur Validierung von VCs integrieren
- Kunden-APIs durch Kombination aus Token und VC absichern
Warum die Kombination aus Tokens & VCs entscheidend ist
Tokens allein bestätigen lediglich eine Zugriffsberechtigung – nicht jedoch die dahinterliegende Identität oder deren Eigenschaften. Verifiable Credentials hingegen sind nicht für die dynamische Echtzeit-Autorisierung von API-Requests ausgelegt.
Erst die Kombination beider Ansätze schafft eine moderne Sicherheitsarchitektur:
- kryptografisch abgesicherte Identität (VCs)
- kurzlebige, dynamische Zugriffsrechte (Tokens)
- datensparsame Authentifizierung im Sinne von Datenschutz und DSGVO
API-Security: Strategischer Mehrwert für Unternehmen
API-Security ist eine grundlegende Voraussetzung für skalierbare digitale Geschäftsmodelle. Richtig umgesetzt, entsteht daraus klarer geschäftlicher Mehrwert:
- Schutz sensibler Daten und kritischer Geschäftsprozesse
- Reduktion von Betriebsunterbrüchen und Sicherheitsvorfällen
- Erfüllung regulatorischer Anforderungen
- Stärkung von Vertrauen bei Kunden und Partnern
API-Security entwickelt sich damit vom technischen Detail zu einem strategischen Enabler moderner Digitalisierung.
Fazit & Ausblick: API-Sicherheit als strategische Daueraufgabe
API-Security ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess entlang des gesamten API-Lifecycles. Entscheidend ist die konsequente Verankerung in Entwicklung, Betrieb und Governance. Zentrale Grundlage ist dabei eine API-Security-Roadmap, die Security frühzeitig in den Entwicklungs- und Betriebsprozess integriert (DevSecOps) und Sicherheit nicht nachgelagert, sondern systematisch verankert. Ergänzend gewinnen Automatisierung und Zero-Trust-Prinzipien zunehmend an Bedeutung.
Wer API-Security strategisch denkt, schafft nicht nur mehr Sicherheit, sondern auch die Grundlage für skalierbare digitale Innovation.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()

Email Spoofing: Weit verbreitete Fehlkonfiguration in Exchange Online
Phishing, Business Email Compromise (BEC), CEO-Fraud, Ransomware – nahezu jede grössere Cyberkampagne beginnt mit einer E-Mail. Entsprechend hoch sind die Investitionen von Unternehmen in Mail-Gateways, Spamfilter und Protokolle wie SPF, DKIM und DMARC.
Im Rahmen aktueller Sicherheitsanalysen hat das InfoGuard Red Team jedoch eine weit verbreitete Fehlkonfiguration bei Microsoft Exchange Online identifiziert. Unter bestimmten Voraussetzungen können Angreifende E-Mails direkt an den Tenant zustellen, ohne die vorgelagerte E-Mail-Sicherheitslösung zu durchlaufen. Dadurch lassen sich etablierte Schutzmechanismen umgehen und E-Mails mit beliebigen internen oder externen Absenderadressen zustellen.
Die Folgen können gravierend sein: Gezielte Phishing-Angriffe lassen sich dadurch über die eigene Maildomäne des Unternehmens durchführen. So könnten sich Angreifende beispielsweise als CEO ausgeben und Mitarbeitende mit täuschend echten internen E-Mails zur Preisgabe von Informationen oder zur Ausführung von Aktionen verleiten.
Ghost-Sender in Exchange Online: Was passiert konkret?
Bei bestimmten Exchange-Online-Konfigurationen können E-Mails unter Umständen direkt an den Tenant zugestellt werden, ohne dass sie die vorgelagerte E-Mail-Sicherheitslösung durchlaufen. Dadurch werden etablierte Schutzmechanismen wie SPF, DKIM, DMARC und Spamfilter umgangen und externe Angreifer können wahlweise interne und externe Absender impersonieren.
Nach Einschätzung von Microsoft handelt es sich nicht um eine Produktschwachstelle, sondern um eine Konfigurationssituation im Zusammenspiel von Exchange Online und vorgelagerten Mail-Gateways.
Wer ist betroffen von Ghost-Sendern?
Typischerweise betroffen sind Organisationen, die:
- Exchange Online (auch im Hybrid-Modus mit Exchange On-Premises) einsetzen, und
- eingehende E-Mails über ein externes Mail-Gateway oder eine Drittanbieter-Sicherheitslösung führen.
Nach unseren Beobachtungen betrifft dies eine Vielzahl von Umgebungen, inklusive grosser und sicherheitstechnisch gut aufgestellter Organisationen.
Ghost-Sender-Risiken: So schliessen Sie blinde Flecken in Exchange Online
E-Mail-Sicherheit endet nicht beim Produktkauf, sondern beginnt bei der präzisen Konfiguration und dem kontinuierlichen Monitoring. Das Ghost-Sender-Szenario zeigt exemplarisch, wie schnell sich blinde Flecken in komplexen Architekturen einschleichen – selbst in Organisationen mit hohen Security-Ansprüchen.
Wer jetzt handelt, kann:
- kritische Konfigurationslücken schliessen,
- Impersonation-Angriffe wirksam erschweren
- und die eigene Cyberresilienz nachhaltig stärken.
Um eine schnelle Erstprüfung zu ermöglichen, hat InfoGuard ghost-sender.com entwickelt.
Ghost-Sender-Test: Mail-Domänen in drei Schritten prüfen
Unsere eigens für dieses Szenario entwickelte Plattform erlaubt es, Mail-Domänen gezielt auf mögliche Ghost-Sender-Risiken zu testen. Zusätzlich steht ein ausführlicher technischer Artikel im InfoGuard-Labs-Blog zur Verfügung.
Wir empfehlen folgende 3 Schritte:
- Domänenprüfung
Prüfen Sie Ihre Mail-Domänen auf ghost-sender.com. - Fachstellen einbinden
Wird eine Betroffenheit festgestellt, wenden Sie sich an Ihren Microsoft-Partner, E-Mail-Provider oder den Betreiber Ihrer Mail-Infrastruktur, um die empfohlenen Schutzmassnahmen zu prüfen und umzusetzen. - Verantwortliche informieren
Informieren Sie die für Ihre E-Mail-Infrastruktur verantwortlichen Personen innerhalb Ihrer Organisation über die Ergebnisse.
Wichtig: Beachten Sie, dass die notwendigen Konfigurationsanpassungen von Ihrer individuellen Exchange-Online- und Mail-Gateway-Umgebung abhängen und nicht zentral durch InfoGuard vorgenommen werden können.
Prüfen Sie jetzt Ihre Mail-Domänen. So verschaffen Sie sich umgehend Klarheit darüber, ob Ihre Organisation von der beschriebenen Konfigurationssituation betroffen ist, erkennen frühzeitig Handlungsbedarf und leiten gemeinsam mit Ihren verantwortlichen Fachstellen gezielt die nächsten Schritte ein.
Deep Dive: Ghost-Sender in Exchange Online verstehen
Im InfoGuard Labs Blog beleuchten wir die technischen Hintergründe des Ghost-Sender-Szenarios im Detail: von den relevanten Exchange-Online- und Mail-Gateway-Konfigurationen bis zu den konkreten Angriffspfaden und Schutzmassnahmen.
Der technische Deep Dive liefert eine fundierte Einordnung der beschriebenen Cyberrisiken und zeigt auf, welche Massnahmen Sie in Ihrer Umgebung prüfen sollten.
Quellen & Referenzen
• Ghost-Sender
• InfoGuard LABS: Universal Email Spoofing against Exchange Online
• NCSC, Cyber Security Hub (CSH): [Advisory] Microsoft Exchange: Arbitrary Email Spoofing
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()

InfoGuard Threat Intelligence Report Q2/26: Europas Cyberrisiko, Salt Typhoon & Irans Rückkehr
Die geopolitische Cyberlage hat im zweiten Quartal gegenüber dem Bericht zum ersten Quartal 2026 deutlich an Schärfe gewonnen. Iran, Salt Typhoon, destruktive OT-Angriffe und autonome KI-Systeme machen deutlich: Europas Cyberrisiko entsteht nicht nur durch neue Angriffe, sondern durch immer schwerer sichtbare Abhängigkeiten, Exponierungen und Detektionslücken. Eine Analyse der wichtigsten Verschiebungen zeigt, wo und inwiefern sich die Lage seit Q1/26 verändert hat.
Seit Q1/2026 verschiebt sich Europas Cyberrisiko
Die Übersicht zeigt die Veränderungen auf einen Blick. Anschliessend ordnen wir die fünf Entwicklungen ein und leiten konkrete Takeaways für die Cyberabwehr ab.
1. Iran nach Epic Fury: Vom Hacktivismus zu APT-Operationen1.1 Weshalb ist Irans digitale Rückkehr ein Cyberrisiko für Europa?
Iran ist seit dem 17. April 2026 nach 47 Tagen digitaler Isolation wieder schrittweise vernetzt – und damit können auch hochspezialisierte APT-Einheiten wieder koordinierter agieren. Im Q1-Report haben wir den 28. Februar 2026 als Zäsur beschrieben: Operation Epic Fury löste sofort eine mehrstufige iranische Cyber-Vergeltungswelle aus, koordiniert durch den neu gegründeten Electronic Operations Room mit über 60 aktiven Gruppen. Was die Situation damals vorübergehend technisch entschärfte: Israel und die USA führten gleichzeitig die grösste Cyberoperation gegen Iran durch, die je dokumentiert wurde. Sie reduzierten damit Irans Internetkonnektivität auf 1-4 %. Auch Akteure hochspezialisierter APT-Einheiten waren damit de facto vom Rest der Welt abgeschnitten.
Das hat sich geändert. Was im Q1 noch als chaotischer, dezentraler Hacktivismus sichtbar wurde, droht nun in koordinierte Cyberoperationen überzugehen. Die Reconnection Irans ist deshalb kein Entwarnungssignal. Sie markiert weit mehr den Beginn der gefährlicheren Phase.
1.2 Warum zielen iranische Akteure auf Rockwell Automation?
Iranisch-affiliierte Gruppen verschieben ihren Fokus von Unitronics-PLCs auf Rockwell Automation FactoryTalk – und damit auf eine grössere Angriffsfläche in Industrie, Energieversorgung und Wasserinfrastruktur. Ende März 2026 identifizierte Unit 42 einen neuen Angriffscluster (CL-STA-1128 / CyberAv3ngers), der diese Zielverschiebung sichtbar macht. Bisher hatten die Gruppen primär Unitronics-PLCs angegriffen – israelische Fabrikate, die vergleichsweise begrenzt eingesetzt werden. Nun rückt mit Rockwell Automation FactoryTalk eine OT-Plattform in den Fokus, die deutlich weiter verbreitet ist.
Aus europäischer Sicht ist das relevant: Denn Rockwell-Systeme sind in der Industrieautomation weltweit flächendeckend im Einsatz – in Produktionsanlagen, Energieversorgung und Wasserinfrastruktur, auch in der DACH-Region. Die Angreifer wählen damit eine Angriffsoberfläche, die grösser und potenziell weniger gehärtet ist als die bisher fokussierten Unitronics-Systeme.
Für Unternehmen mit Rockwell-Umgebungen ist das keine abstrakte Warnung. CyberAv3ngers hat bewiesen, dass sie OT-Systeme nicht nur kompromittieren, sondern auch aktiv manipulieren. In früheren Kampagnen wurden Konfigurationen verändert und Prozesse gestört, ohne dass Wiper oder Ransomware notwendig waren.
1.3 RedKitten: Der neue technisch hochentwickelte Akteur
Parallel zu CyberAv3ngers ist ein neu identifizierter iranischer Akteur aufgetaucht, der sich technisch deutlich von den bisherigen Gruppen unterscheidet: RedKitten. Die Gruppe nutzt eine Angriffsmethodik, die explizit darauf ausgelegt ist, unter dem Radar normaler Sicherheitstools zu bleiben.
Die Kernmechanik: Die Angreifenden nutzen präparierte Dokumente, um die SloppyMIO-Backdoor auszuführen. Diese liest per Steganografie Konfigurationsdaten aus Bilddateien auf legitimen Code-Repositories aus. Payloads werden über Cloud-Storage nachgeladen. Die gesamte Kommunikation läuft ausschliesslich über Messaging-Platform-APIs – eine sogenannte Dead-Drop-Resolver-Architektur, die bösartigen Traffic in gewöhnlichem Cloud-Rauschen versteckt.
Das Ergebnis: Traditionelle signaturbasierte Erkennung und netzwerkbasierte Anomalie-Detection greifen nicht, weil der Traffic wie normales SaaS-Nutzungsverhalten wirkt. Nach der öffentlichen Exposition Ende 2025 tauschte RedKitten seine Infrastruktur rasch aus und weitete das Targeting auf über 20 Länder aus – inklusive Westeuropa.
1.4 Europa im Fokus koordinierter Cyberangriffe
Ein für Europa besonders relevantes Muster des laufenden Konflikts: Pro-iranische und pro-russische Hacktivisten-Gruppen koordinieren ihre Cyberoperationen opportunistisch. SOCRadar hat für den ersten Kriegsmonat (28. Februar bis 31. März 2026) 1.357 dokumentierte Incidents in über 25 Ländern und 15 Sektoren erfasst. Zypern wurde mit 68 Incidents zum zweitgrössten europäischen Ziel – nicht zufällig, sondern weil es US-Militärinfrastruktur beherbergt und geographisch exponiert ist. Rumänien folgt mit 58 Incidents.
NoName057(16) nutzt die Iran-Operationen für sogenannte Double-Benefit-Hits: dieselbe DDoS-Welle trifft gleichzeitig iranische Gegner und NATO-Mitglieder im Kontext des Ukraine-Kriegs. Für betroffene europäische Organisationen ist die Attribution dabei oft unklar – und das ist gewollt.
Einschätzung Q2/2026
Wir befinden uns jetzt in der Phase, vor der Analysten seit Februar 2026 gewarnt haben: koordinierte APT-Operationen, keine Ablenkungsmanöver. Organisationen in den Sektoren Energie, Industrie, Telekommunikation und öffentliche Verwaltung sollten ihre Exponierung gegenüber Rockwell-Systemen, VPN-Gateways und exponierten OT-Umgebungen neu bewerten. Die Reconnection Irans ist kein Entwarnungssignal – sie markiert das Ende der Aufwärmphase.
2. China: Salt Typhoon erreicht Nordeuropa
In unserem Q1-Report haben wir Chinas Strategie als Pre-Positioning für einen möglichen Taiwan-Konflikt beschrieben: eine stille, jahrelange Kompromittierung kritischer Infrastruktur, ohne Alarm zu schlagen. Q2/2026 bringt die europäische Bestätigung dessen, was viele bereits ahnten.
2.1 Norwegen: Die erste skandinavische Bestätigung
Im Februar 2026 veröffentlichte Norwegen seinen jährlichen Bedrohungsbericht. PST-Direktorin Beate Gangås bestätigte darin explizit: Salt Typhoon hat Netzwerkgeräte in norwegischen Organisationen kompromittiert – die erste offizielle skandinavische Bestätigung, dass die lange als US-Problem wahrgenommene Kampagne Nordeuropa erreicht hat.
Die Formulierung der PST war bemerkenswert direkt: Norwegen stehe vor seiner schwersten Sicherheitslage seit dem Zweiten Weltkrieg. Norwegens Sicherheitsbehörden beschreiben China, Russland und Iran nicht als abstrakte Bedrohungen, sondern als aktiv operierende Geheimdienste auf norwegischem Boden.
2.2 Die strategische Neubewertung durch ODNI 2026
Das US Office of the Director of National Intelligence stuft chinesische Cyberoperationen im Annual Threat Assessment 2026 neu ein: Volt Typhoon und Salt Typhoon gelten nicht mehr primär als Spionagekampagnen, sondern als Pre-Positioning in kritischer Infrastruktur – mit dem Ziel, Sabotage für potenzielle Konflikte vorzubereiten.
Diese Neubewertung ist für Europa relevant, weil sie die Stossrichtung klarstellt: China baut keine Nachrichtendienstlichen Fähigkeiten auf, es baut Schalter ein. Schalter, die in einer geopolitischen Krise – Taiwan, Handelskrieg, militärische Eskalation – aktiviert werden können. Die europäische Infrastruktur ist dabei nicht Ziel, sondern Hebel: Wer Europa destabilisieren kann, schwächt westliche Unterstützung für Taiwan.
2.3 LOTL in Nordeuropa: Warum Salt Typhoon so schwer zu finden ist
Salt Typhoon und Volt Typhoon teilen eine Methodik, die sie für traditionelle Sicherheitsarchitekturen nahezu unsichtbar macht: Living-off-the-Land. Keine Malware, nur native Systemtools. Keine Command-and-Control-Server mit auffälligen Domains, nur kompromittierte SOHO-Router als Relay-Infrastruktur. In mehreren dokumentierten Fällen blieben die Gruppen bis zu fünf Jahre unentdeckt.
Für Organisationen in Skandinavien, den Niederlanden, Deutschland und Österreich bedeutet das: Die Frage ist nicht mehr nur, ob chinesische Akteure bereits in europäischen Netzwerken präsent sind, sondern ob diese Präsenz bekannt ist. Die Wahrscheinlichkeit dafür ist, basierend auf den verfügbaren Daten, erheblich.
Einschätzung Q2/2026
Die norwegische Bestätigung ist kein Einzelfall. Sie ist die erste öffentlich bestätigte Spitze eines europäischen Eisbergs. Telekommunikations-, Energie- und Verteidigungsunternehmen in Europa sollten davon ausgehen, dass Netzwerkgeräte an der Perimeter – Firewalls, VPN-Concentrators, Switches – primäre Angriffsflächen sind. Diese Geräte sind systematisch unzureichend überwacht und haben typischerweise keine EDR-Abdeckung.
3. Russland: «Below Threshold» als permanente Kriegsführung
Russlands Cyberstrategie gegen Europa ist keine Reaktion auf aktuelle Ereignisse. Sie ist eine dauerhaft angelegte Zermürbungskampagne mit klar definiertem Ziel: maximalen Schaden verursachen, ohne die Article-5-Schwelle der NATO zu überschreiten und eine kollektive militärische Reaktion auszulösen. Q2/2026 macht dieses Kalkül an einem konkreten Fall sichtbar.
3.1 Polen Dezember 2025: Der erste bestätigte destruktive OT-Angriff in der EU
Im Dezember 2025 – einem Monat mit unterdurchschnittlicher Gesamtzahl an Sicherheitsvorfällen – wurde Polen Ziel einer der schwerwiegendsten Cyberoperationen gegen EU-Infrastruktur. Russisch-affiliierte Angreifer kompromittierten Kontrollsysteme im Energiesektor. Kritische Steuerungssysteme wurden gestört, und Industrieausrüstung wurde dauerhaft beschädigt – physisch, nicht «nur» digital. Reparatur statt Wiederherstellung.
Doch entscheidend ist, was nicht passierte: Kein weitreichender Blackout, keine Todesopfer, kein Anlass für eine Article-5-Konsultation. Das Ereignis bleibt genau unterhalb der Eskalationsschwelle, kostet aber polnische Energieversorger Millionen, destabilisiert Vertrauen in kritische Systeme und sendet eine unmissverständliche Botschaft an NATO-Mitglieder, die die Ukraine unterstützen.
Der Atlantic Council dokumentiert in einem Report vom April 2026 über 150 Sabotage-, Cyber- und Influence-Incidents in Europa seit 2022 – mit zunehmender Frequenz und zunehmender Destruktivität. Das Muster ist konsistent: testen, eskalieren, einfrieren, wiederholen.
3.2 Das Vakuum der US-Cyber-Abschreckung
Wenn US-Cyber-Abschreckung nachlässt, steigt für Europa der Druck, eigene Cyberkapazitäten strategischer zu denken. CEPA stellt in einem Bericht vom März 2026 einen Zusammenhang fest: Wo Intelligence-Sharing eingeschränkt wird, koordinierte Reaktionen ausbleiben und Operationen ohne NATO-Vorabinformation erfolgen, sinken die Kosten für russische hybride Angriffe.
Die Logik ist simpel: Wenn die Kosten sinken, steigt die Aktivität. Aus Sicht europäischer Sicherheitsarchitekten ist das ein Wendepunkt. Europa kann nicht mehr davon ausgehen, dass US-Cyber-Kapazitäten als verlängerte Abschreckung wirken. Das ist keine Katastrophe – es ist eine strategische Realität, die Europas eigene Kapazitäten in den Vordergrund rückt.
Einschätzung Q2/2026
Russlands Below-Threshold-Modell ist keine Übergangsphase. Es ist die neue Normalität. Energieversorger, Infrastrukturbetreiber und staatliche Stellen müssen damit rechnen, dass OT-Systeme nicht mehr nur als Spionageziele gelten. Sie gelten zunehmend als Ansatzpunkte für physische Sabotage. Der Dezember-Angriff auf Polen ist ein «Proof of Concept», kein Einzelfall.
4. Warum Angreifer keinen Co-Piloten brauchen4.1 KI-Angriffe und Asymmetrie – ein Flugzeugvergleich
Ein modernes Verkehrsflugzeug kann heute vollständig autonom fliegen. Autopilot, automatische Landung, Kollisionswarnung – technisch gesehen, wäre kein menschlicher Pilot nötig. Trotzdem sitzt in jedem kommerziellen Flugzeug mindestens ein ausgebildeter Mensch im Cockpit. Der Grund ist simpel: Bei 300 Passagieren an Bord sind die Konsequenzen eines Fehlers katastrophal und irreversibel. Das System kann 9.999 Flüge perfekt durchführen, beim 10.000sten muss ein Mensch eingreifen können.
Cyber Defence funktioniert nach exakt demselben Prinzip: Ein unbemerkter Angriff, ein ungeblockter Payload oder ein False Negative auf einem produktiven System kann reichen. Die Verteidigung muss immer gewinnen. Deshalb ist Human-in-the-Loop zwingend: erfahrene Analysten, die Kontext einordnen, Anomalien bewerten und Entscheidungen verantworten.
Für den Angreifer gilt exakt das Gegenteil. Wenn ein autonomer Angriff scheitert, kostet das nichts. Keine menschlichen Stunden, kein Operator, der Konsequenzen trägt. Einfach den nächsten starten – schneller, billiger, mit angepasster Methodik. Die Asymmetrie ist fundamental: Die Verteidigung muss immer, ein Angriff muss nur einmal gewinnen. KI macht den Angriff beliebig skalierbar und wiederholbar: Was scheitert, wird angepasst und erneut gestartet. Für die Verteidigung bleibt die Fehlertoleranz gering. Sie muss automatisieren, aber menschliches Urteilsvermögen in der Beurteilungsschleife behalten.
4.2 Vom KI-Tool zur autonomen Cyberattacke
KI in Cyberangriffen ist nicht neu. Seit Jahren wird KI für Spear-Phishing-Personalisierung, automatisierte Vulnerability-Scans und Malware-Varianten genutzt. Was sich in Q2/2026 verändert hat, ist die Qualität: von KI als Werkzeug zu KI als autonomem Akteur.
Armis-Threat-Intelligence-Chef, Michael Freeman, hat es konkret formuliert: Bis Mitte 2026 wird mindestens ein globales Unternehmen durch ein vollständig autonomes agentic AI-System kompromittiert – mit Reinforcement Learning und Multi-Agent-Koordination für den kompletten Angriffs-Lifecycle ohne menschliche Aufsicht. Reconnaissance, Exploitation, Laterale Bewegung, Datenexfiltration – alles automatisiert, alles ohne menschliches Eingreifen. Das WEF Global Cybersecurity Outlook 2026 zeigt: 87 % der befragten Sicherheitsverantwortlichen weltweit nennen KI-Schwachstellen als die am schnellsten wachsende Bedrohung.
Nation-State-Akteure sind hier nicht Nachzügler, sondern Treiber: Berichte aus der Threat-Intelligence-Community zeigen, dass staatlich gesteuerte Gruppen bereits 90 % ihrer Intrusion-Kampagnen automatisieren. Chinesische Akteure haben laut Anthropic-Bericht (November 2025) vollständig automatisierte Angriffsketten gegen Technologieunternehmen und Regierungsstellen eingesetzt. Iran arbeitet nachweislich an AI-gestützten Spear-Phishing-Systemen.
4.3 RaaS goes Autonomous: Wenn Ransomware nicht verhandelt, sondern vernichtet
Auch in der kriminellen Ransomware-Szene zeigt sich das Muster. Q1/2026 brachte eine Rekonsolidierung des Marktes: Qilin, LockBit und The Gentlemen expandieren. Qilin hat inhouse Legal Services eingeführt, um Druck auf Opfer zu erhöhen. Die Global Group lancierte AI-Chatbots für Verhandlungen – autonome Systeme, die Lösegeldforderungen anpassen, Fristen setzen und kommunizieren, ohne menschliche Intervention.
Die Sicarii-Gruppe geht noch weiter: Ihre Ransomware löscht die eigenen Entschlüsselungsschlüssel nach der Verschlüsselung – eine Waffe, die nicht auf Erpressung abzielt, sondern auf permanente Zerstörung. Eine Zahlung ist sinnlos. Wiederherstellung ist unmöglich. Das ist der Übergang von Ransomware als Geschäftsmodell zu Ransomware als Sabotagewaffe.
4.4 KI-Asymmetrie: Cyberabwehr erfordert Human-in-the-Loop
Die KI-Asymmetrie stellt Sicherheitsarchitekturen vor ein strukturelles Problem: Je mehr Automatisierung auf der Angreiferseite, desto höher ist der Druck, auf der Verteidigerseite ebenfalls zu automatisieren – aber die Fehlertoleranz bleibt asymmetrisch. Automatisierte Defense-Systeme können false positives produzieren, die den Betrieb stören, oder false negatives, die Angriffe durchlassen. Jede Fehlentscheidung in der Abwehr birgt Konsequenzen. Für Angreifende hingegen bedeutet ein Fehlversuch nur Trainingsmaterial für den nächsten Angriff.
Das führt zu einer Konsequenz, die kontraintuitiv erscheint, aber operativ richtig ist: Je autonomer Angriffe werden, desto wichtiger wird der menschliche Threat Hunter. Nicht als Reaktion auf Alarme, sondern als proaktiver Jäger in Umgebungen, in denen automatisierte Systeme systematisch umgangen werden.
Einschätzung Q2/2026
Autonome KI-Angriffe sind kein Zukunftsszenario mehr. Sie sind operativ. Die Verteidigung muss diese Asymmetrie akzeptieren: Automatisierung auf der Verteidigerseite ist notwendig, aber nicht ausreichend. Das Co-Piloten-Modell gilt weiterhin – technische Systeme fliegen das Flugzeug, aber ein erfahrener Mensch muss eingreifen können, wenn es darauf ankommt.
In die Welt der Cybersecurity übersetzt, heisst dieses Co-Piloten-Modell: Threat Hunting. Gemeint ist eine vertiefte Analyse der Exponierungsrisiken durch erfahrene Incident Responder, die sichtbar macht, was automatisierte Systeme oft übersehen – Spuren, Anomalien und Angriffsmuster, die erst im Kontext der aktuellen Bedrohungslage erkennbar werden.
5. Der unbequeme Verbündete: Die USA aus europäischer Sicht
Vorbemerkung zum Ton dieses Kapitels: Was folgt, ist keine Kritik an den USA als Land oder Verbündeten. Es ist die nüchterne Anwendung einer Grundregel internationaler Politik, die seit dem Westfälischen Frieden 1648 gilt: Jeder Staat handelt primär im eigenen Interesse. Das ist weder überraschend noch verwerflich – es ist die Realität jedes souveränen Akteurs, inklusive der europäischen Staaten selbst. Die Frage ist nur, ob Europa das als gegeben akzeptiert und entsprechend handelt.
5.1 CYBERCOM 2.0 und die Normalisierung offensiver Cyberoperationen
Im Januar 2026 wurde vor dem US-Senatsausschuss für Streitkräfte die bisher grösste Transformation des US Cyber Command präsentiert: CYBERCOM 2.0. Die zuständige Assistant Secretary of War for Cyber Policy beschrieb es als «die bedeutendste Transformation des USCYBERCOM seit seiner Gründung vor über 15 Jahren» – eine fundamentale Neuaufstellung, die offensive Dauerpräsenz in gegnerischen Netzwerken als Routineinstrument etabliert.
Im März 2026 folgte Trumps neue Nationale Cyberstrategie: explizit aggressiver als alle Vorgänger, mit dem Ziel, Bedrohungen «vor» dem Erreichen amerikanischer Netzwerke zu begegnen. Das Konzept des «Persistent Engagement» – kontinuierliche offensive Operationen in gegnerischer Infrastruktur – wird zur offiziellen Doktrin.
Was bedeutet das für Europa? Zwei Dimensionen: Zum einen stärkt eine leistungsfähigere US-Cyberkapazität die kollektive Abschreckung gegen Russland, China und Iran – davon profitiert Europa indirekt. Zum anderen normalisiert die USA offensive Cyberoperationen als legitimes Staatsmittel auf einer neuen Ebene. Europa wird sich fragen müssen, wie es mit diesem Präzedenzfall umgeht – und ob die gleiche Doktrin, die gegen Moskau vertretbar erscheint, auch das Vertrauen in US-Technologieinfrastruktur beeinflusst.
5.2 CLOUD Act: Das strukturelle Souveränitätsproblem
Das vielleicht konkreteste Risiko für die europäische Cybersicherheit geht nicht von einem Angriff aus, sondern von einem Gesetz. Der US CLOUD Act (Clarifying Lawful Overseas Use of Data Act) erlaubt US-Behörden, von US-amerikanischen Unternehmen Zugang zu Daten zu verlangen – unabhängig davon, wo diese Daten physisch gespeichert sind.
Im Juni 2025 wurde Microsoft France in einer Anhörung vor dem französischen Senat direkt gefragt: Können Sie garantieren, dass europäische Kundendaten nie von US-Behörden angefordert werden? Die Antwort war eindeutig und unter Eid: Nein. Diese Garantie kann nicht gegeben werden. Nicht weil Microsoft das nicht will, sondern weil Microsoft eine US-amerikanische Gesellschaft ist und US-Recht für US-Gesellschaften überall auf der Welt gilt.
Das betrifft nicht nur Microsoft. AWS kann dieselbe Garantie nicht geben. Google auch nicht. Jeder US-Hyperscaler, jede US-basierte Sicherheitslösung, jedes US-EDR – sie alle unterliegen demselben rechtlichen Rahmen. Ein europäisches Rechenzentrum ändert die Geografie der Daten, aber nicht die Jurisdiktion über das Unternehmen.
Für die Cybersecurity-Architektur europäischer Organisationen hat das konkrete Implikationen: Wer US-basierte Sicherheitstools einsetzt – und das ist die grosse Mehrheit – hat potenziell einen dritten Akteur im Netzwerk. Nicht zwangsläufig böswillig, aber ausserhalb europäischer Kontrolle und europäischen Rechts. In einer Zeit, in der sich die Interessen der USA und Europas in Handelsfragen, Geopolitik und Verteidigung zunehmend auseinanderbewegen, ist das eine strategische Variable, die ins Kalkül gehört.
5.3 Drei Incidents – ein Muster
Drei öffentlich dokumentierte Incidents der letzten 15 Monate illustrieren das Muster:
- Signal-Leak (März 2025): US-Verteidigungsminister Pete Hegseth besprach Militärpläne über eine nicht klassifizierte kommerzielle App und teilte sie versehentlich mit einem Journalisten. Intern bezeichnete er Europa als «Freeloaders». Europäische Verbündete erfuhren von den Militäraktionen aus der Presse statt über sichere Kanäle.
- Grönland (August 2025): Dänischer Rundfunk DR berichtete, gestützt auf Geheimdienstquellen, dass mindestens drei Trump-nahe Personen verdeckte Einflussoperationen auf dänischem Territorium (Grönland) durchführten. Dänemarks Aussenminister bestellte den US-Botschafter ein. Dänemarks Premierminister formulierte öffentlich: «You cannot spy against an ally.»
- Operation «Epic Fury» (Februar 2026): Die USA und Israel starteten eine Militäroperation gegen Iran, die zur Tötung des Obersten Führers führte und die gesamte Golfregion destabilisierte – ohne vorherige Information an NATO-Verbündete. Der Atlantic Council schreibt explizit: «Trump apparently caught NATO, Gulf, and Asian allies off guard, reportedly providing no advance warning.» Das ist keine Kommunikationspanne. Das ist eine strategische Entscheidung.
Diese drei Incidents sind keine Ausreisser. Sie sind das Muster einer Administration, die «Amerika First» konsequent umsetzt – rational aus US-Perspektive, herausfordernd aus europäischer. Was sie gemeinsam haben: Europa war in keinem dieser Fälle eine gleichwertige strategische Variable in der US-Kalkulation.
5.4 Europas Cybersicherheit verlangt digitale Souveränität
Die Antwort auf diese Analyse ist weder Feindbildkonstruktion noch naiver Vertrauensverlust, sie ist strategische Mündigkeit. Europa sollte von der US-Allianz profitieren, wo sie Vorteile bietet – und gleichzeitig aufhören, US-Interessen mit europäischen Interessen gleichzusetzen.
Konkret bedeutet das für die Cybersicherheit: Europäische digitale Souveränität ist keine Anti-Amerika-Politik. Es ist die logische Konsequenz aus der Erkenntnis, dass Abhängigkeit von fremder Infrastruktur, ob chinesisch, russisch oder amerikanisch, ein Sicherheitsrisiko darstellt. Die EU hat mit dem Cloud Sovereignty Framework (Oktober 2025), dem Cyber Resilience Act und EuroStack erste Schritte in diese Richtung gemacht. Es ist nicht genug – aber es ist die richtige Richtung.
Einschätzung Q2/2026
Jeder Staat handelt im eigenen Interesse. Das ist keine Kritik. Es ist die Grundregel, nach der jede Sicherheitsstrategie gebaut sein sollte. Für europäische Organisationen bedeutet das praktisch: US-Technologie dort einsetzen, wo sie die beste Lösung ist – aber mit dem Wissen um den rechtlichen Rahmen (CLOUD Act, FISA) und mit Architekturentscheidungen, die kritische Daten und Systemzugänge unter europäischer Kontrolle halten.
6. Die Detektionslücke bleibt – das Expositionsdefizit wächst
Die Kernerkenntnis aus unserem Q1-Report hat sich deutlich verschärft: 57 % aller Kompromittierungen werden nicht durch eigene Sicherheitssysteme entdeckt, sondern durch externe Hinweise. Die mediane Verweildauer eines Angreifers in europäischen Netzwerken liegt bei 22 Tagen (EMEA-Median, Mandiant M-Trends 2025).
Im Q2/2026 verschärft sich vor allem die Detektionsfrage: LOTL-Angriffe (Living-off-the-Land) waren bereits für signaturbasierte Systeme unsichtbar. Autonome KI-Angriffe ohne festes Timing, ohne menschliches Verhaltensmuster und ohne statische Infrastruktur stellen auch verhaltensbasierte Anomalie-Detection vor neue Herausforderungen. RedKittens Dead-Drop-Resolver-Architektur, die vollständig über legitime Cloud-APIs kommuniziert, zeigt, wohin die Entwicklung geht: Angriffs-Traffic, der von normalem SaaS-Traffic nicht mehr zu unterscheiden ist.
Zur Detektionslücke tritt die Risikoexposition in den Vordergrund: Exponierte Systeme, übersehene Abhängigkeiten, falsch priorisierte Schwachstellen und unzureichend überwachte Zugänge schaffen Bedingungen, in denen Angriffe leichter vorbereitet und verborgen werden können.
Genau dieses Muster bestätigt sich in der Incident-Response-Praxis: Staatliche Angreifer fallen selten durch Alarme auf, sondern durch externe Hinweise, Zufallsfunde oder ältere Zugangspfade, die erst bei einem anderen Vorfall sichtbar werden.
6.1 Proaktives Threat Hunting: Suchen, bevor ein Alarm entsteht
Proaktives Threat Hunting durch erfahrene Incident Responder ist in der aktuellen Bedrohungslage – Iran Phase 2, China in Nordeuropa, Russland destruktiv in Polen, autonome KI-Angriffe operativ – keine optionale Ergänzung zur bestehenden Sicherheitsarchitektur. Es setzt genau dort an, wo automatisierte Systeme an Grenzen stossen: bei Spuren, Hypothesen und Angriffsmustern, für die es noch keinen Alarm gibt.
Der Unterschied zu automatisierten Systemen liegt im Ansatz: Threat Hunter starten nicht mit einem Alarm. Sie starten mit einer Hypothese – basierend auf aktueller Threat Intelligence, dem Profil der Organisation und dem Wissen, wie staatliche Angreifer in vergleichbaren Umgebungen operieren. Sie suchen nicht nach bekannten Mustern. Sie suchen nach dem, was sichtbar sein müsste, wenn die aktuelle Bedrohungslage bereits in der eigenen Umgebung angekommen ist.
CISAs eigenes Threat-Hunting-Team hat gezeigt, was das bedeutet: Es hat Volt Typhoon in US-Infrastruktur gefunden – in Umgebungen, in denen alle anderen automatisierten Systeme versagt hatten. Nicht weil das Team bessere Tools hatte. Sondern weil erfahrene Incident Responder wissen, wo man sucht.
6.2 Compromise Assessment: Kompromittierung und Exponierung erkennen
Für Organisationen, die noch kein regelmässiges Threat Hunting betreiben, kann ein Compromise Assessment eine sinnvolle Standortbestimmung sein: eine forensische Überprüfung, ob bereits Hinweise auf eine Kompromittierung vorliegen – methodisch, mit aktuellem Wissen über die Taktiken der relevanten Bedrohungsakteure.
Als Momentaufnahme reicht das jedoch nur begrenzt. Wer die aktuelle Bedrohungslage ernst nimmt, betrachtet Kompromittierung und Exponierung gemeinsam: Gibt es Anzeichen für laufende oder frühere Angriffe? Und welche Angriffsflächen erhöhen das Risiko, dass daraus der nächste Vorfall entsteht?
Angesichts der Lage im Q2/2026 – Iran Phase 2 online, China in Nordeuropa bestätigt, Russland destruktiv aktiv, autonome KI-Angriffe operativ – geht es nicht um Aktionismus, sondern um belastbare Entscheidungsgrundlagen. Je später Organisationen Klarheit über Kompromittierung und Risikoexposition gewinnen, desto stärker hängen sie von externen Hinweisen, Zufallsfunden oder dem nächsten Vorfall ab.
Fazit: Cyberresilienz braucht Detektion und Risikoklarheit
Q2/2026 ist kein Fortsetzungsartikel. Es ist eine Zuspitzung. Iran ist nach 47 Tagen wieder online und wechselt von Hacktivismus zu koordinierten APT-Operationen mit neuen OT-Zielen. China hat Skandinavien erreicht. Russland hat in Polen erstmals Industrieanlagen dauerhaft zerstört, ohne eine NATO-Reaktion zu provozieren. Autonome KI-Angriffe sind operativ. Und der Blick auf die eigene Allianz zeigt: Strategische Eigenständigkeit ist keine Isolation – es ist die notwendige Konsequenz aus der Erkenntnis, dass kein Verbündeter die eigenen Interessen über die eigenen stellt.
Für Organisationen folgt daraus: Proaktives Threat Hunting und die kontinuierliche Bewertung der Risikoexposition gehören zusammen. So entsteht kein Versprechen absoluter Sicherheit, sondern ein belastbarer Umgang mit einer Angriffsfläche, die sich laufend verändert.
Ob bereits Spuren einer Kompromittierung bestehen und welche Angriffsflächen das reale Risiko erhöhen, lässt sich nur beantworten, wenn Threat Hunting und Managed Risk Exposure zusammengedacht werden. Die Erkenntnisse aus Threat Hunting, Incident Response und Threat Intelligence der letzten Monate liefern dafür eine fachliche Grundlage.
Am Anfang einer Caberrisikoanalyse steht eine nüchterne Standortbestimmung: Was ist kompromittiert, was ist exponiert – und was muss zuerst reduziert werden? Nutzen Sie das Whitepaper «InfoGuard Threat Intelligence Insights 2025» als Realitätscheck: Erfahren Sie, welche Angriffsmuster jetzt besonders relevant sind und welche Schritte für Ihre Organisation jetzt Priorität haben.
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()

Kürzere TLS-Zyklen: Automatisiertes Zertifikatsmanagement wird Pflicht
Das Ende langer TLS-Zertifikatslaufzeiten
Bisher waren TLS-Zertifikate (Transport Layer Security) oft über ein Jahr gültig. Das gab IT-Teams ausreichend Zeit für manuelle Erneuerungsprozesse. Doch nun geht diese Ära ihrem Ende entgegen. Das CA/Browser-Forum (CA/B), das Gremium, das die globalen Standards für Zertifikate festlegt, hat offiziell dafür gestimmt, die Gültigkeitsdauer von TLS-Zertifikaten schrittweise drastisch zu verkürzen.
Der Zeitplan für diese Umstellung ist bereits fixiert:
- Bis März 2026: Die maximale Laufzeit beträgt noch 398 Tage.
- Ab März 2026: Reduzierung auf 200 Tage.
- Ab März 2027: Reduzierung auf 100 Tage.
- Ab März 2029: Die maximale Laufzeit wird nur noch 47 Tage betragen.
Warum kürzere TLS-Laufzeiten notwendig sind
Die drastische Verkürzung der Zertifikatslaufzeiten adressiert ein reales und wachsendes Problem. Denn viele Unternehmen haben heute nur begrenzte Transparenz über ihre Fare-Zertifikatslandschaft und reagieren oft erst, wenn ein Zertifikat abläuft oder ein Vorfall eintritt. In komplexen IT-Umgebungen mit hunderten oder tausenden Zertifikaten führt dies regelmässig zu Ausfällen, Sicherheitslücken oder Compliance-Problemen.
Je länger ein Zertifikat gültig ist, desto grösser ist das Risiko, dass kompromittierte oder veraltete kryptographische Verfahren unbemerkt im Einsatz bleiben. Gleichzeitig nimmt die Geschwindigkeit, mit der neue Bedrohungen und Anforderungen entstehen, stetig zu.
Genau hier setzt die Verkürzung der Laufzeiten an. Sie zwingt Unternehmen, ihre Prozesse zu modernisieren und von reaktiven, manuellen Ansätzen auf automatisierte und kontrollierte Abläufe umzustellen.
Kürzere Laufzeiten bringen damit klare Vorteile:
- Erhöhte Sicherheit: Kompromittierte Zertifikate können deutlich kürzer missbraucht werden
- Schnellere Reaktionsfähigkeit: Unternehmen müssen neue Standards und Algorithmen rascher umsetzen
- Vorbereitung auf Post-Quantum-Kryptographie: Krypto-Agilität wird zur Pflicht
Gerade im Hinblick auf zukünftige Bedrohungen durch Quantencomputing wird es entscheidend, kryptographische Verfahren schnell austauschen zu können.
Certificate Lifecycle Management (CLM): Automation ist Pflicht
Für Unternehmen bedeutet dies einen deutlich steigenden Administrationsaufwand. Wenn ein Zertifikat nur noch 47 Tage gültig ist, muss der Erneuerungsprozess faktisch alle paar Wochen fehlerfrei durchlaufen werden. Eine manuelle Verwaltung, die bei hunderten oder gar tausenden Zertifikaten bereits heute fehleranfällig ist, wird bei diesem Tempo zu einem erhöhten Risiko für Ausfälle.
Ungeplante Zertifikatsabläufe führen zu:
- Service-Downtimes: Websites und Anwendungen sind nicht mehr erreichbar.
- Sicherheitslücken: Ungeschützte Datenübertragungen und Compliance-Verstösse.
- Überlastung der IT-Teams: Mitarbeitende werden durch repetitive Routineaufgaben von strategischen Projekten abgezogen.
Kurz gesagt: Ohne Automatisierung wird Zertifikatsmanagement zum Betriebsrisiko.
DigiCert als Leader im Zertifikatsmanagement
Moderne Lösungen für Certificate Lifecycle Management (CLM) setzen genau hier an. Um der Herausforderung immer kürzerer Zertifikatslaufzeiten effektiv zu begegnen, setzen wir auf unseren Partner DigiCert.
DigiCert ist ein weltweit führender Anbieter für Digital Trust und sichert Menschen, Daten und Geräte mit KI-gestützten Lösungen, um Bedrohungen zu stoppen und eine quantensichere Zukunft zu ermöglichen. Mehr als 100’000 Organisationen, darunter 90 % der Fortune 500, vertrauen auf DigiCert, um ihre digitale Infrastruktur zu sichern und sich auf zukünftige Bedrohungen vorzubereiten.
Warum DigiCert?
- Vollständige Transparenz: Zentrale Übersicht über alle Zertifikate durch CA-agnostische Discovery, kontinuierliches Monitoring sowie Alerts in Echtzeit – für volle Kontrolle über die gesamte Zertifikatslandschaft.
- Automatisierung: End-to-End-Automatisierung des gesamten Zertifikatslebenszyklus – reduziert Fehler und verhindert Ausfälle.
- Skalierbarkeit: Nahtlose Integration in Multi-Cloud- und Hybrid-Umgebungen sowie bestehende IT- und DevOps-Prozesse.
- Sicherheit & Kontrolle: Durchsetzung von Richtlinien, klare Auditierbarkeit und frühzeitige Erkennung von Risiken.
- Zukunftssicherheit: PQC-Ready (Post-Quantum-Kryptographie) und flexibel anpassbar an neue Standards und Anforderungen.
Praxisbeispiel – Zertifikatsmanagement auf Knopfdruck
Wie gross der Effekt der Automatisierung sein kann, zeigt ein Praxisbeispiel von DigiCert aus dem Schweizer Healthcare-Bereich. In einer komplexen Infrastruktur mit über 10’000 Zertifikaten war das Zertifikatsmanagement früher stark manuell geprägt. Heute wird die gesamte Umgebung von nur einer Person überwacht.
Dort, wo früher manuell eingegriffen werden musste, nutzt das Unternehmen heute die DigiCert-API.
- Über 450 interne Anwendungs-Endpunkte wurden erfolgreich für die automatische Registrierung (Auto-Enrollment) konfiguriert.
- Auch für interne Webserver läuft der Prozess nun vollautomatisch ab.
- Das Beste daran: Für die Server-Administratoren war keine Schulung erforderlich, da die bestehenden Workflows im Hintergrund effizienter wurden.
Durch den Wechsel auf die containerisierte DigiCert ONE-Plattform ist das Unternehmen nicht nur bereit für die Cloud (Azure-Migration), sondern auch für die kommende Ära der Post-Quantum-Kryptographie (PQC). Die Plattform ermöglicht es, schnell auf neue kryptographische Standards zu reagieren, ohne die gesamte Infrastruktur umbauen zu müssen.
InfoGuard & DigiCert – eine Partnerschaft für Ihr CLM
Mit DigiCert setzt InfoGuard auf einen der weltweit führenden Anbieter im Bereich Digital Trust. Im aktuellen IDC MarketScape «Worldwide Certificate Lifecycle Management Software 2026 Vendor Assessment» wurde DigiCert erneut als Leader positioniert.
Unsere Expert:innen unterstützten Sie gemeinsam mit DigiCert dabei, Ihr Zertifikatsmanagement nachhaltig zu transformieren.
Ihre Vorteile:
- Analyse bestehender Zertifikate und Prozesse
- Einführung automatisierter CLM-Lösungen
- Integration in bestehende IT- und Security-Architekturen
- Vorbereitung auf zukünftige Anforderungen wie PQC
So schaffen Sie die Grundlage für eine Zertifikatsinfrastruktur, die nicht nur heute zuverlässig funktioniert, sondern auch langfristig sicher, skalierbar und effizient betrieben werden kann.
Erfahren Sie mehr über den Trust Lifecycle Manager von DigiCert oder sprechen Sie mit unseren Expert:innen über Ihre CLM-Strategie.
Autor: Natacha Suter
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()

Cyber Threat Intelligence: Risikoexpositionen erkennen, bevor Angreifer es tun
Rein hypothetisch: Wo würden Sie als Cyberkriminelle:r Ihren Angriff starten? Mit Sicherheit dort, wo der Aufwand klein und die Wirkung gross ist. Die meisten Angriffe entstehen nicht aus hochspezialisierten Einzeloperationen, sondern aus Opportunitäten. Cyberkriminelle suchen skalierbare Eintrittspunkte, automatisieren die Suche und verwerten erfolgreiche Zugänge weiter. So wird ein kompromittierter Unternehmenszugang zum verwertbaren Einstiegspunkt.
Angriffsflächen 2025 in Zahlen: von Phishing bis zur Supply ChainPhishing ungeschlagen: 43 % aller Angriffe beginnen hier
Cyberkriminelle versuchen durch kompromittierte E-Mail-Accounts, weitere Benutzer:innen zu phishen. Mit LLMs lassen sich Phishing-Szenarien mit geringem Aufwand skalieren. So sind die meisten Phishingangriffe weniger gezielt als opportunistisch: Entscheidend ist die Quantität der versendeten E-Mails.
25 % schlecht geschützte Remote Services
Angreifer testen exponierte Login Prompts systematisch mit Brute Force oder Password Spraying. Dabei nutzen sie bekannte Benutzername-Passwort-Kombinationen, geleakte Passwörter, typische Varianten und erkennbare Muster in der Passwortwahl von Mitarbeitenden. Entsprechend zählen Brute Force und Password Spraying zu den häufigen Angriffsvektoren, die 2025 im InfoGuard Security Operations Center (SOC) als True Positive erkannt wurden.
20 % exponierte Schwachstellen: Patchfenster schrumpfen weiter!
Gemäss Zerodayclock werden Schwachstellen 2026 im Schnitt bereits nach 2,1 Tagen ausgenutzt gegenüber 21,5 Tagen im Vorjahr. Diese Beschleunigung setzt klassische Patchprozesse massiv unter Druck. Ein wesentlicher Treiber sind KI-Tools, die sowohl die Erkennung von Schwachstellen als auch die Entwicklung von Exploits erleichtern.
12 % Supply Chain: Wenn Vertrauen zur Angriffsfläche wird
Partner und Lieferanten stellen Software, Services und Hardware bereit, warten Systeme über Remotezugänge oder unterstützen geschäftskritische Prozesse. Genau dadurch wird die eigene Sicherheit zunehmend von der Sicherheit Dritter abhängig. Supply-Chain-Risiken entstehen dort, wo Vertrauen, technische Abhängigkeiten und externe Zugriffe zusammenkommen.
Krimineller Markt: Wenn Unternehmenszugänge handelbar werden
Die häufigsten Eintrittspunkte zeigen: Der erste Zugriff auf eine Unternehmensumgebung ist längst nicht mehr nur ein technisches Problem, sondern Teil eines kriminellen Markts. Initial Access Broker beschaffen, prüfen und verkaufen solche Zugänge weiter. Was früher der Auftakt eines einzelnen Cyberangriffs war, ist heute Teil der cyberkriminellen Wertschöpfungskette.
Dabei zählt Skalierbarkeit. Cyberkriminelle sammeln möglichst viele Zugänge, bewerten deren Schadenpotenzial und verkaufen besonders lohnende Einstiege weiter. Ein kompromittiertes VPN-Konto, ein gültiger Remote-Zugang, ein gekaperter Cloud-Account oder Zugriff auf ein internes System kann bereits genügen – etwa für Ransomware, Datendiebstahl, Erpressung oder Spionage.
Für Unternehmen bedeutet das: Der eigentliche Angriff beginnt oft lange bevor Ransomware ausgeführt oder Daten gestohlen werden – nämlich dann, wenn ein Zugang unbemerkt kompromittiert und in kriminellen Lieferketten weitergereicht wird.
«Gehandelt werden nicht blosse Logins, sondern Zugriffschancen und damit die Möglichkeit, ein Unternehmen für Erpressung, Betrug oder Spionage verwertbar zu machen.»
Gestohlene Zugangsdaten: Warum die Rolle über den Schaden entscheidet
Welche Zugänge abfliessen und wie sie missbraucht werden, hängt vom Kompromittierungsweg und der betroffenen Rolle ab.
Die folgenden Beispiele zeigen, wie unterschiedlich das Schadenspotenzial je nach Funktion ausfällt:
Mitarbeitende
- E-Mail-Konten: Business E-Mail Compromise, internes Phishing, Zugriff auf vertrauliche Kommunikation, Passwort-Resets
- M365/Google Workspace Account: SharePoint, OneDrive, Teams/Chat, Kalender, interne Dokumente
- Session Cookies und Browser Tokens: Zugriff ohne Passwort ohne erneute MFA-Abfrage
- VPN-Konten: Einstieg ins interne Netzwerk
- Passwort-Manager-Inhalt: Zugriff auf weitere interne und externe Dienste
Vertrieb/Verkauf
- CRM-Zugänge: Kundendaten, Pipeline, Verträge, Kontaktlisten
- E-Mail-Konten: Rechnungsbetrug
- Signierungs-Lösungen: Manipulation oder Missbrauch von Vertragsprozessen
- Kundenportal-Zugang: Kundendaten, Servicefälle, Bestellungen
Helpdesk/IT-Support
- Helpdesk-Accounts: Passwort-Resets, Account-Recovery, Benutzerinformationen
- Ticketing-System: interne Probleme, Systemnamen, laufende Projekte
- Remote-Support-Zugänge: Direkt-Zugriff auf Endgeräte und Server
- MDM- und Endpoint-Management-Zugänge: Geräteverwaltung, Softwareverteilung, Policy-Änderungen
- MFA-Reset oder MFA-Registrierungsrechte: Übernahme fremder Accounts
Engineering / IT-Betrieb
- VPN- und Jumphost-Zugänge: Zugriff auf interne Administrationszonen
- SSH-Keys: Zugriff auf Linux-Server, Netzwerkgeräte, Appliances
- Domänen-Admin: Vollständige Kompromittierung der Windows-Umgebung
- Cloud-Admin-Zugänge: Zugriffe auf virtuelle Geräte, Storage, IAM, Datenbanken, Backup
- Kubernetes-Admin-Zugänge: Zugriff auf Cluster, Secrets, Workloads, Container
Softwareentwicklung / DevOps
- GitHub-/GitLab-/Bitbucket-Zugänge: Quellcode-Diebstahl, Suche nach Secrets, Codemanipulation
- CI/CD-Secrets: Manipulation von Builds und Deployments
- Deployment Tokens: Veröffentlichung manipulierte Software in Produktion
- Container-Registry-Zugänge: Einschleusen bösartiger Images
- Package-Registry-Zugänge: Supply-Chain Angriffe über manipulierte Pakete
- Signing-Zertifikate: Signieren manipulierte Software
- Secrets auf lokalen Entwicklermaschinen: Seiteneinstieg in Build-, Test-, Produktionsumgebungen
- Webhook-Secrets: Manipulation von Integrationen und Automationen
Identitäten härten und überwachen: 7 Massnahmen gegen kompromittierte Identitäten
Identitäten gehören heute zu den wichtigsten Angriffszielen. Oft brauchen Angreifer keine Malware und keine komplexe Schwachstelle. Ein gültiges Passwort, ein gestohlener Session-Cookie oder ein manipulierter MFA-Prozess genügt. Identitätsschutz muss deshalb als eigene Sicherheitsdisziplin verstanden werden, nicht als reine IT-Administrationsaufgabe.
Folgende sieben Massnahmen zeigen, wie Organisationen Identitäten, Zugriffe und Sessions wirksam absichern:
- Benutzerkonten mit phishing-resistenter MFA absichern
Alle Benutzerkonten brauchen starke Authentifizierung. MFA ist Pflicht, aber nicht jede MFA ist phishing-resistent: SMS-Codes und einfache Push-Bestätigungen lassen sich umgehen. Wirksamer sind FIDO2 Security Keys, Passkeys oder zertifikatsbasierte Verfahren – besonders für privilegierte Konten, Helpdesk-Rollen sowie Zugriffe auf Cloud-, VPN- und Remote-Access-Systeme. - Anmeldungen mit Conditional Access bewerten
Conditional Access bewertet nicht nur Benutzername, Passwort und MFA, sondern auch den Kontext der Anmeldung: Gerät, Standort, Browser, Zugriffsmuster und Sensibilität der Daten. So lassen sich riskante Logins blockieren, zusätzliche Prüfungen erzwingen oder Zugriffe auf vertrauenswürdige Geräte beschränken. - Privilegierte Identitäten streng kontrollieren
Admin-Konten brauchen getrennte Zugänge, starke MFA, «Just-in-Time»-Zugriff, rollenbasierte Berechtigungen und lückenloses Logging. Dauerhaft aktive Global-Admin-, Domain-Admin- oder Cloud-Admin-Rechte erhöhen das Risiko unnötig. Privilegien sollten nur bei Bedarf vergeben und danach automatisch wieder entzogen werden. - Passwörter nicht unterschätzen
Passwörter bleiben relevant, besonders ohne phishing-resistente Authentifizierung. Entscheidend sind starke Passwörter oder Passphrases, keine Wiederverwendung, keine geleakten oder Standard-Passwörter und keine gemeinsam genutzten Konten. Passwortmanager helfen bei der sicheren Verwaltung; langfristig sollten passwortlose Verfahren zum Zielbild werden. - Session-Schutz: MFA endet nicht nach dem Login
Angreifer stehlen zunehmend Browser-Cookies und Tokens, um MFA zu umgehen. Deshalb sollten Unternehmen riskante Sessions erkennen, Token-Lebenszeiten begrenzen, Re-Authentication bei sensiblen Aktionen verlangen und Zugriffe von nicht verwalteten Geräten einschränken. Der Schutz endet nicht nach dem Login - Helpdesk-Prozesse absichern
Cyberkriminelle umgehen technische Schutzmassnahmen oft über den Support, etwa durch manipulierte MFA-Resets, neue Geräte-Registrierungen oder Passwortänderungen. Helpdesk-Prozesse brauchen deshalb klare Identitätsprüfungen, Vier-Augen-Prinzipien und Alarme bei sensiblen Änderungen. Ein schwach abgesicherter Helpdesk kann selbst starke MFA aushebeln. - Identity Use Cases für Monitoring und Detection definieren
Logs allein reichen nicht. Entscheidend sind konkrete Identity-Use-Cases für Monitoring und Detection: unmögliche Reisebewegungen, ungewöhnliche Herkunftsländer, gehäufte Login-Fehler, unübliche MFA-Registrierungen, neue Geräte, verdächtige OAuth-Freigaben, Passwort-Reset-Anomalien, privilegierte Rollenänderungen oder massenhafte Dateizugriffe. Identitäten müssen geschützt und laufend überwacht werden.
«Nicht jede Anmeldung ist vertrauenswürdig, nur weil das Passwort stimmt.»
Eine starke Identity-Sicherheitsstrategie wirkt erst im Zusammenspiel: robuste Authentifizierung, kontextbasierte Zugriffe, minimale Rechte, sichere Admin-Prozesse, Session-Schutz, laufendes Monitoring und schnelle Reaktion bei verdächtigen Anmeldungen.
Wie stark Identitäten 2025 ins Zentrum realer Cybervorfälle gerückt sind, zeigt das Whitepaper «InfoGuard Threat Intelligence Insights 2025». Es ordnet aktuelle Angriffsmuster ein und zeigt, welche Massnahmen Organisationen priorisieren sollten, um Account Takeover früher zu erkennen und gezielter zu verhindern.
Endpunkte und Server überwachen: Angriffe erkennen, bevor sie eskalieren
Auch starke Identity Security schliesst nicht jede Lücke. Angreifer können über Schwachstellen, gestohlene Sessions, kompromittierte Lieferanten oder bereits vorhandene Zugänge in eine Umgebung gelangen. Ab diesem Moment entscheidet Sichtbarkeit darüber, ob ein Angriff früh erkannt wird oder ob sich Angreifer ungestört weiterbewegen.
EDR-Abdeckung: Sensorik auf den entscheidenden Systemen
Systeme mit Zugriff auf Unternehmensdaten oder interne Infrastrukturen brauchen eine möglichst vollständige EDR-Abdeckung: Arbeitsplätze, Notebooks, Server, virtuelle Maschinen, Terminalserver, Admin-Systeme und kritische Applikationsserver. Besonders wichtig sind Systeme, auf denen privilegierte Benutzer:innen arbeiten oder über die auf geschäftskritische Daten zugegriffen wird.
EDR ist dabei nicht einfach ein weiteres Tool, sondern die Sensorik auf dem System selbst. Sie erkennt verdächtige Prozessketten, ungewöhnliche Skriptausführung, Credential Dumping, laterale Bewegung, Ransomware-Verhalten oder Manipulationen an Sicherheitstools. Ohne diese Sichtbarkeit erkennt ein Unternehmen oft nur noch die Folgen – nicht aber den eigentlichen Ablauf des Angriffs.
Wenn EDR nicht möglich ist: Sichtbarkeit anders herstellen
Nicht jedes System lässt sich mit einem EDR-Agenten ausstatten. Legacy-Systeme, Produktionsanlagen, Appliances, Netzwerkgeräte, Mainframes, OT-Systeme oder hochkritische Plattformen mit Stabilitätsanforderungen brauchen kompensierende Kontrollen. Wo EDR nicht möglich ist, müssen mindestens administrative Zugriffe kontrolliert, protokolliert und überwacht werden – etwa über gehärtete Jump Hosts oder Admin Workstations mit EDR-Abdeckung.
Zusätzlich braucht es Netzwerksichtbarkeit durch Network Detection and Response (NDR) sowie zentrale Logs im SIEM. NDR hilft, laterale Bewegung, ungewöhnliche Verbindungen, Command-and-Control-Kommunikation, Scans oder Datenabfluss zu erkennen. Gerade dort, wo kein Endpoint-Agent installiert werden kann.
Kritische Server: Keine blinden Flecken in der Eskalationszone
Besonders kritisch ist die Überwachung von Servern mit hoher Bedeutung. Domain Controller, Identity-Systeme, Backup-Server, Virtualisierungsplattformen, File Server, Datenbanken, Applikationsserver, CI/CD-Systeme, Management-Server, EDR-/SIEM-Komponenten und Cloud Connectoren. Wer nur Benutzer-Endgeräte überwacht, aber Server, Linux-Systeme, virtuelle Umgebungen oder Admin-Infrastruktur vernachlässigt, erkennt möglicherweise den Einstieg –verpasst aber die Eskalation.
Der entscheidende Punkt: Jede Ausnahme braucht Transparenz. Unternehmen müssen wissen, welche Systeme existieren, welche davon EDR haben, welche Ausnahmen bestehen und welche kompensierenden Kontrollen greifen. «Fast überall» reicht nicht, wenn ausgerechnet kritische Systeme blind bleiben.
Managed Risk Exposure: Welche Risiken zuerst reduziert werden müssen
Neben Identitätsschutz sowie Endpunkt- und Server-Monitoring braucht es eine dritte zentrale Fähigkeit, die eigene Angriffsfläche kontinuierlich zu prüfen. Denn viele Angriffe beginnen nicht mit hochkomplexen Exploits, sondern damit, was nach aussen sichtbar, falsch konfiguriert, vergessen oder nicht sauber verantwortet ist.
Dazu gehören unmanaged Assets, exponierte Systeme, Shadow IT, Fehlkonfigurationen, ungepatchte Schwachstellen und technische Angriffspfade, die Angreifer schneller finden als die eigene Organisation. Genau hier entsteht ein gefährlicher blinder Fleck: Organisationen schützen häufig, was sie kennen – kompromittiert werden sie über das, was niemand mehr auf dem Radar hatte.
Von Schwachstellenlisten zu echten Cyberrisiken
Managed Risk Exposure erweitert klassisches Vulnerability Management um den entscheidenden Kontext: Es geht nicht nur darum, CVEs zu scannen und Tickets zu erstellen. Entscheidend ist die tatsächliche Angriffsfläche: Welche Systeme sind von aussen erreichbar? Welche Identitäten haben kritische Rechte? Welche Cloud-Ressourcen sind falsch konfiguriert? Welche Lieferanten- oder Remote-Zugänge existieren? Welche Schwachstellen lassen sich realistisch zu einem Angriffspfad kombinieren?
Der wichtigste Punkt: Nicht alles kann gleichzeitig behoben werden. Deshalb braucht es risikobasierte Priorisierung. Eine kritische Schwachstelle auf einem isolierten Testsystem ist nicht automatisch wichtiger als eine mittlere Schwachstelle auf einem exponierten System mit Zugriff auf produktive Daten. Entscheidend sind Erreichbarkeit, Kritikalität, vorhandene Kontrollen, mögliche Auswirkungen und Wahrscheinlichkeit zur Ausnutzung.
Identifizierte Risiken sollten deshalb laufend priorisiert werden. Diese Liste ist kein statisches Reporting-Artefakt, sondern ein operatives Steuerungsinstrument. Sie zeigt, welche Risiken mit den verfügbaren Ressourcen zuerst reduziert werden müssen und welche Massnahmen den grössten Sicherheitsgewinn bringen.
Die typischen Bereiche sind:
- Unmanaged Assets: Systeme ohne Besitzer, EDR, Patch-Prozess oder Inventarisierung
- Exposed Assets: Internet-erreichbare Server, VPN-Portale, Remote-Zugänge, Admin-Oberflächen, Cloud-Dienste
- Shadow IT: Nicht freigegebene SaaS-Dienste, private Cloud-Ressourcen, vergessene Subdomains, inoffizielle Tools
- Fehlkonfigurationen: Offene Storage Buckets, zu breite Firewall-Regeln, schwache IAM-Rollen, unsichere Standardkonfigurationen
- Schwachstellen: Ungepatchte Systeme, veraltete Software, bekannte Exploit-Pfade, fehlende Härtung
- Angriffspfade: Kombinationen aus Exponierung, Identitäten, Berechtigungen, Netzwerkzugriff und Schwachstellen
Findings übersetzen: Was technisch auffällt, muss geschäftlich relevant sein
Besonders wertvoll wird dieser Ansatz, wenn technische Findings nicht isoliert betrachtet werden. Ein offener Port ist noch kein Risiko in verständlicher Sprache. Ein exponiertes Admin-Interface ohne MFA auf einem geschäftskritischen System dagegen schon. Genau diese Übersetzung ist entscheidend: Aus technischen Findings werden priorisierte Risiken, die Management und Technik gemeinsam verstehen und bearbeiten können.
Cyberresilienz beginnt mit einem realistischen Lagebild
Ein jährlicher Blick auf die Angriffsfläche reicht nicht. Neue Systeme, Cloud-Projekte, Lieferanten, Software-Releases, Berechtigungen, Akquisitionen oder Schatten-IT verändern die Sicherheitslage laufend. Wer seine Angriffsfläche nur einmal jährlich prüft, ist praktisch immer zu spät. Entscheidend ist ein wiederkehrender Prozess: Risiken identifizieren, bewerten, priorisieren, Massnahmen umsetzen und deren Wirkung überprüfen.
Das InfoGuard Whitepaper «Threat Intelligence Insights 2025» vertieft diese Perspektive auf Basis von über 350 realen Cybervorfällen, die wir im Jahr 2025 bearbeitet haben. Es zeigt, welche Angriffspfade besonders relevant sind, warum Identitäten, Sichtbarkeit und Reaktionsfähigkeit 2026 weiter an Bedeutung gewinnen. Im Mittelpunkt stehen konkrete Erkenntnisse aus realen Angriffsmustern. So entsteht ein Lagebild, das nicht bei der Analyse stehen bleibt, sondern hilft, Monitoring gezielt auszubauen, Prozesse zu testen und Entscheidungen fundierter zu treffen.
Nutzen Sie das Whitepaper «InfoGuard Threat Intelligence Insights 2025» als Realitätscheck: Prüfen Sie, welche Angriffsmuster jetzt besonders relevant sind – und welche Massnahmen für Ihre Organisation Priorität haben.
Ein Angriff. Ein blinder Fleck. Eine Chance, das zu ändern.
Sandro Bachmann, Principal Threat Intelligence Analyst, weiss aus täglicher Praxis: Ein Angriff läuft selten so ab, wie man ihn erwartet.
Im «Cyber Threat Intelligence Webinar» vom 27. Mai 2026 zeigt er, wie moderne Bedrohungen wirklich funktionieren und woran Organisationen Risikoexpositionen frühzeitig erkennen.
- Wann: Mittwoch, 27. Mai 2026 | 10.00 – 10.45 Uhr
- Wo: virtuell
Sind Sie dabei? Einfach anmelden und teilnehmen. Wir freuen uns auf Sie!
InfoGuard AG
Lindenstrasse 10
CH6340 Baar
Telefon: +41 (41) 7491900
https://www.infoguard.ch
Marketing Manager
Telefon: +41 (41) 74919-00
E-Mail: estelle.ouhassi@infoguard.ch
![]()