• Cybersicherheit ist Chefsache: Warum NIS-2 die Geschäftsführung in die Pflicht nimmt

    VonJ. Benjamin Espagné

    Cybersicherheit ist längst kein reines IT-Thema mehr — sie ist Chefsache. Das wird spätestens mit NIS-2 und dem EU AI Act auch regulatorisch unmissverständlich. In einem aktuellen Beitrag für contentway bringt Dr. Andreas Herch, CEO der Business Unit accompio Enterprise, die zentrale Botschaft auf den Punkt: Wer Cyberresilienz will, braucht Führung — nicht nur Technik.

    NIS-2 macht Cybersicherheit zur Pflichtaufgabe der Geschäftsführung

    Die NIS-2-Richtlinie und der EU AI Act heben das Schutzniveau in Europa auf ein verbindlicheres Level. Was früher als freiwillige Kür galt — Risikomanagement, Incident Response, Business Continuity, Audits — wird jetzt Pflicht. Und die Verantwortung liegt nicht mehr bei der IT-Abteilung allein, sondern direkt bei der Geschäftsführung. Inklusive persönlicher Haftung.

    Dr. Herch formuliert es klar: Cybersicherheit ist eine strategische Führungsaufgabe geworden. Unternehmen müssen Prozesse, Governance und Verantwortlichkeiten strukturell verankern. NIS-2 zwingt dazu — und das ist im Kern keine Bedrohung, sondern eine Chance.

    Der blinde Fleck: Fokus auf Technik statt auf Menschen

    Ein zentraler Punkt des Artikels verdient besondere Aufmerksamkeit: Häufig liegt der Fokus von IT-Organisationen zu stark auf der Technik. Die Mitarbeitenden, deren Verhalten oft die Haupteinfallstore sind, werden dagegen häufig vergessen. Firewalls und Endpoint Protection sind notwendig — aber ohne Awareness-Programme, klare Governance-Strukturen und definierte Verantwortlichkeiten bleiben sie Lösungen für nur die Hälfte des Problems.

    Organisatorische Maßnahmen sind neben den technischen Schritten genauso wichtig: Governance-Strukturen aufbauen, Verantwortlichkeiten klar definieren, zentrale Aufgaben so verteilen, dass sie nicht in Zuständigkeitslücken fallen.

    Der richtige Startpunkt: Security-IST-Analyse

    Dr. Herch empfiehlt Unternehmen, zunächst einen erfahrenen Dienstleister mit einer Security-IST-Analyse zu beauftragen — Status quo und Benchmark ermitteln, bevor investiert wird. Das klingt selbstverständlich, wird aber in der Praxis oft übersprungen. Stattdessen wird in teure Software investiert, ohne zu wissen, wo die tatsächlichen Lücken liegen.

    Erst ein Audit, das die komplette Bandbreite einer möglichen Cyberstrategie durchspielt, deckt NIS-2-Lücken auf und lenkt den Fokus auf die relevanten Baustellen. Darauf aufbauend lässt sich ein passendes Sicherheitskonzept ableiten.

    Schlüsselführungsfragen für die Geschäftsführung

    Der Artikel nennt eine Reihe von Fragen, die jede Geschäftsführung beantworten können sollte — und die in der Praxis erschreckend oft unbeantwortet bleiben:

    Wie sind wir IT-technisch für einen Produktionsausfall vorbereitet? Wie aktuell ist unser Notfallkonzept? Wurden alle NIS-2-Vorgaben umgesetzt? Wo haben wir noch Lücken? Deckt unsere Cyber-Versicherung unser Geschäftsmodell ab?

    Wenn diese Fragen nicht spontan und substanziell beantwortet werden können, ist das ein klares Signal: Es besteht Handlungsbedarf — und zwar auf Führungsebene, nicht in der IT-Abteilung.

  • Cyberrisiken finanziell messbar machen: Warum Cybersicherheit in die Sprache des Vorstands übersetzt werden muss

    VonJ. Benjamin Espagné

    Was man nicht messen kann, kann man auch nicht steuern. Dieser Grundsatz gilt in der Betriebswirtschaft seit Jahrzehnten — nur in der Cybersicherheit wird er konsequent ignoriert. Unternehmen investieren jährlich erhebliche Mittel in Security-Maßnahmen, ohne ein echtes Verständnis dafür zu haben, welche Risiken sie damit tatsächlich adressieren — und welche nicht.

    In einem aktuellen Interview für contentway erläutert Asdrúbal Pichardo, Managing Director und CEO von Squalify, warum die finanzielle Quantifizierung von Cyberrisiken ein zentraler Hebel für bessere Sicherheitsentscheidungen ist.

    Cyberrisiken als betriebswirtschaftliche Größe

    Das Kernproblem: Cybersicherheit wird in den meisten Unternehmen weiterhin als Angelegenheit der IT-Abteilung behandelt. Investitionen orientieren sich an Checklisten oder subjektiven Einschätzungen statt an messbaren Auswirkungen auf das Geschäft. Die Folge: Vorstände und Geschäftsführer können nicht beurteilen, ob jeder investierte Euro dort wirkt, wo er das Unternehmen tatsächlich schützt.

    Squalify verfolgt einen anderen Ansatz: Das Unternehmen übersetzt Cyberrisiken in finanzielle Kennzahlen — ROI, EBIT, Cashflow. Damit sprechen IT und Vorstand endlich die gleiche Sprache. Das Cyberrisiko wird auf Unternehmensebene betrachtet: die Konsequenzen eines Cyber-Vorfalls auf das Unternehmen quantifiziert, mit direkter Relevanz für die Geschäftsführung.

    42 Datenpunkte für belastbare Risikoaussagen

    Bemerkenswert ist die Effizienz des Ansatzes: Anhand von nur 42 Datenpunkten berechnet die Squalify-Plattform bereits belastbare Zahlen mit Vorstandsrelevanz. Das Quantifizierungsmodell basiert auf historischen Daten zu tatsächlichen Cyber-Verlusten von mehr als 100.000 Unternehmen weltweit und der Expertise von Munich Re, einem der führenden Cyber-Rückversicherer.

    Die Ergebnisse werden auf Basis eines standardisierten, an Unternehmensdaten angepassten Modells in finanzielle Kennzahlen übersetzt. Das ermöglicht präzise Risikoaussagen mit minimalem Aufwand — ein entscheidender Vorteil gegenüber klassischen Risk-Assessments, die oft Monate dauern und trotzdem abstrakt bleiben.

    Typische Anwendungsfälle

    Unternehmen nutzen die Plattform laut Pichardo vor allem, um festzustellen, welche Investitionen in Cybersicherheit den größten Effekt haben und das Risiko am stärksten reduzieren. Gerade Großunternehmen setzen Squalify außerdem zur transparenten Steuerung von Tochtergesellschaften oder für objektive Benchmarks mit Wettbewerbern ein. Darüber hinaus unterstützt die Plattform bei der Auswahl geeigneter Cyberversicherungen.

    Warum das für die Geschäftsführung relevant ist

    Die finanzielle Quantifizierung von Cyberrisiken adressiert ein Problem, das mit NIS-2 akuter denn je ist: Geschäftsführer haften persönlich für die Angemessenheit ihrer Sicherheitsmaßnahmen. Doch wie weist man Angemessenheit nach, wenn man die Risiken nicht beziffern kann? Wer seine Cyberrisiken in Euro ausdrücken kann, trifft bessere Entscheidungen — und kann diese gegenüber Aufsichtsbehörden, Versicherern und Geschäftspartnern belegen.

    Der Ansatz zeigt, wohin sich die Branche entwickelt: Weg vom Bauchgefühl, hin zu datengetriebenen Sicherheitsentscheidungen auf Vorstandsebene.

  • Wenn KI die Seiten wechselt: 6 Wege, wie Angreifer KI-Dienste gegen Ihr Unternehmen einsetzen

    VonJ. Benjamin Espagné

    Künstliche Intelligenz verändert die Cybersecurity-Landschaft — aber nicht nur auf der Verteidigerseite. Angreifer nutzen dieselben KI-Dienste, die Unternehmen für Produktivität und Innovation einsetzen, als Angriffsinfrastruktur. Dabei geht es längst nicht mehr nur um KI-generierte Phishing-Mails. Die Methoden sind systematischer, kreativer und gefährlicher geworden.

    Der CSO-Online-Autor Roger Grimes hat sechs zentrale Missbrauchsmuster identifiziert, die wir hier mit zusätzlichen Quellen und unserer Einschätzung einordnen.

    1. KI-gestütztes Social Engineering und Phishing

    Large Language Models erzeugen Phishing-Mails, die sprachlich, kontextuell und stilistisch kaum noch von legitimer Kommunikation zu unterscheiden sind. Angreifer nutzen ChatGPT, Claude oder lokale Open-Source-Modelle, um in Sekunden hunderte individualisierte Nachrichten zu generieren — in jeder Sprache, in jedem Tonfall. Laut einer Studie von SlashNext stieg die Zahl KI-generierter Phishing-E-Mails allein 2024 um über 1.200 Prozent. Harvard Business Review berichtet, dass 60 Prozent der Empfänger auf KI-generierte Phishing-Mails hereinfallen — eine Rate, die mit manuell erstellten, gezielten Spear-Phishing-Angriffen vergleichbar ist.

    Besonders perfide: Die Modelle werden mit öffentlich verfügbaren Informationen aus LinkedIn, Unternehmenswebsites und Pressemitteilungen gefüttert. Das Ergebnis sind hochgradig personalisierte Nachrichten, die gezielt Vertrauensverhältnisse ausnutzen.

    2. Deepfake-Audio und -Video für CEO-Fraud

    Deepfake-Technologie ist kein Zukunftsszenario mehr — sie ist operatives Angriffswerkzeug. Angreifer klonen Stimmen von Geschäftsführern und Vorständen aus öffentlich verfügbaren Aufnahmen (Podcasts, Konferenz-Talks, YouTube-Videos) und setzen sie für CEO-Fraud ein. Der prominenteste Fall: Ein Finanzangestellter in Hongkong überwies 25 Millionen US-Dollar, nachdem er in einer Videokonferenz von Deepfake-Versionen seiner Kollegen und seines CFOs überzeugt wurde.

    Laut dem BSI-Lagebericht 2024 nimmt die Qualität von Deepfake-Angriffen rapide zu. Voice-Cloning benötigt heute nur noch wenige Sekunden Audiomaterial und ist mit frei verfügbaren Tools realisierbar. Für Unternehmen bedeutet das: Jede telefonische oder videobasierte Freigabe-Anforderung ohne Out-of-Band-Verifikation ist ein Sicherheitsrisiko.

    3. KI-generierter Schadcode und polymorphe Malware

    Angreifer nutzen KI-Modelle, um Malware zu erzeugen, die sich bei jeder Ausführung verändert — sogenannte polymorphe Malware. Sicherheitsforscher von Hoxhunt und Picus Security haben nachgewiesen, dass aktuelle LLMs in der Lage sind, funktionsfähige Exploit-Codes, Obfuscation-Layer und Evasion-Techniken zu generieren. Picus Security dokumentierte im “Red Report 2025”, dass KI-gesteuerte Malware-Kampagnen um 500 Prozent zugenommen haben.

    Selbst wenn die großen Anbieter Schutzmechanismen einbauen (Guardrails), werden diese systematisch umgangen — durch Prompt Injection, Jailbreaks oder durch den Einsatz unzensierter Open-Source-Modelle wie WormGPT oder FraudGPT, die explizit für kriminelle Zwecke trainiert wurden.

    4. Automatisierte Schwachstellensuche und Reconnaissance

    Was früher Wochen manueller Arbeit erforderte, erledigen KI-gestützte Tools in Minuten. Angreifer setzen Large Language Models ein, um öffentlich zugängliche Informationen (OSINT) systematisch auszuwerten, Angriffsflächen zu kartieren und bekannte Schwachstellen automatisch mit Exploit-Code zu verknüpfen. Google DeepMind zeigte mit Project Naptime, dass KI-Agenten eigenständig Schwachstellen in Software finden können — und das mit einer Erfolgsrate, die menschliche Analysten in bestimmten Szenarien übertrifft.

    Für Angreifer senkt das die Eintrittsbarriere massiv: Technisch weniger versierte Akteure können mit KI-Unterstützung Angriffe durchführen, die früher APT-Gruppen vorbehalten waren. Das NCSC (National Cyber Security Centre, UK) bestätigte in seinem 2024-Assessment, dass KI die Geschwindigkeit und Effektivität von Cyberangriffen nachweislich erhöht.

    5. Missbrauch legitimer KI-Infrastruktur

    Ein besonders unterschätzter Angriffsvektor: Angreifer nutzen die API-Infrastruktur legitimer KI-Dienste als Teil ihrer Angriffskette. Dazu gehört die Nutzung von KI-Plattformen zur Datenexfiltration (Zusammenfassungen sensibler Dokumente generieren lassen), die Verwendung von KI-Code-Assistenten zur Identifikation von Schwachstellen in gestohlenem Quellcode, sowie die Nutzung von KI-Übersetzungsdiensten für mehrsprachige Angriffskampagnen.

    Microsoft und OpenAI dokumentierten bereits 2024, dass staatlich unterstützte Hackergruppen — darunter Gruppen aus Russland (Forest Blizzard/APT28), China (Charcoal Typhoon), Nordkorea (Emerald Sleet) und dem Iran (Crimson Sandstorm) — aktiv ChatGPT für Reconnaissance, Skripting und Social Engineering nutzen.

    6. Prompt Injection und Manipulation von KI-Agenten

    Mit der zunehmenden Integration von KI-Agenten in Geschäftsprozesse (Kundensupport, Datenanalyse, automatisierte Workflows) entsteht eine neue Angriffsfläche: Prompt Injection. Angreifer schleusen manipulierte Anweisungen in Datenquellen ein, die von KI-Agenten verarbeitet werden — etwa in E-Mails, Dokumente oder Webseiten. Der Agent führt dann Aktionen im Kontext seiner Berechtigungen aus, ohne dass ein Mensch eingreift.

    OWASP hat Prompt Injection in seine Top-10-Liste der LLM-Sicherheitsrisiken aufgenommen (Platz 1). Forscher von Anthropic, Google und Microsoft haben unabhängig voneinander demonstriert, wie Indirect Prompt Injection in Enterprise-Szenarien zu Datenabfluss, unautorisiertem Zugriff und Manipulation von Geschäftsentscheidungen führen kann.

    Was bedeutet das für Unternehmen?

    Die Konvergenz von KI und Cyberangriffen verschärft eine ohnehin angespannte Bedrohungslage. Unternehmen müssen ihre Sicherheitsarchitektur anpassen — und zwar nicht irgendwann, sondern jetzt. Drei Handlungsfelder sind dabei zentral:

    Sichtbarkeit schaffen: Wer nicht sieht, was in seinem Netz passiert, erkennt weder KI-generierte Phishing-Mails noch den Missbrauch interner KI-Dienste. Ein funktionierendes SIEM ist die Grundvoraussetzung.

    Prozesse härten: Freigabeprozesse müssen gegen Deepfake-Angriffe abgesichert werden. Das bedeutet: Multi-Faktor-Verifikation für kritische Transaktionen — nicht nur technisch, sondern auch organisatorisch (Callback-Verfahren, Out-of-Band-Bestätigung).

    KI-Nutzung regulieren: Unternehmen brauchen klare Richtlinien für den Einsatz von KI-Diensten — inklusive Monitoring, welche Daten an externe KI-Plattformen fließen. Shadow AI ist das neue Shadow IT.

  • Cyber Resilience Act: Was der CRA für Ihr Unternehmen bedeutet

    VonJ. Benjamin Espagné

    Der EU Cyber Resilience Act (CRA) ist seit Ende 2024 in Kraft und entfaltet ab dem 11. Juni 2026 erste Wirkung. Mit ihm schafft die EU erstmals einen einheitlichen Rechtsrahmen für die Cybersicherheit von Produkten mit digitalen Elementen — von der Firmware im Router bis zur Cloud-basierten Unternehmenssoftware. Für Hersteller, Importeure und Händler gelten weitreichende neue Pflichten. Aber auch für Unternehmen, die solche Produkte einsetzen, ändert sich mehr als auf den ersten Blick erkennbar.

    Worum geht es beim CRA?

    Der CRA verfolgt einen horizontalen Ansatz: Er reguliert nicht einzelne Branchen, sondern alle Produkte mit digitalen Elementen, die in der EU in Verkehr gebracht werden. Das umfasst Hardware mit eingebetteter Software ebenso wie eigenständige Softwareprodukte. Betroffen sind unter anderem Firewalls, Router, Switches, industrielle Steuerungen, Smart-Home-Geräte, aber auch Business-Software, ERP-Systeme und Cloud-Dienste.

    Im Kern verlangt der CRA:

    • Security by Design: Cybersicherheit muss von der Konzeption bis zum Ende des Produktlebenszyklus mitgedacht werden
    • Schwachstellenmanagement: Hersteller müssen bekannt gewordene Schwachstellen aktiv managen und Sicherheitsupdates bereitstellen — kostenlos und über einen definierten Zeitraum
    • Meldepflichten: Aktiv ausgenutzte Schwachstellen müssen innerhalb von 24 Stunden an die ENISA gemeldet werden
    • Konformitätsbewertung: Produkte müssen vor dem Inverkehrbringen nachweislich die CRA-Anforderungen erfüllen — je nach Risikoklasse durch Selbstbewertung oder durch eine unabhängige Prüfstelle
    • Dokumentationspflichten: Technische Dokumentation, Software Bill of Materials (SBOM) und Konformitätserklärung werden Pflicht

    Zeitplan: Was gilt ab wann?

    Der CRA tritt stufenweise in Kraft:

    • Ab 11. Juni 2026: Pflichten für Konformitätsbewertungsstellen greifen
    • Ab 11. September 2026: Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle
    • Ab 11. Dezember 2027: Alle CRA-Anforderungen gelten vollständig — Produkte ohne CRA-Konformität dürfen nicht mehr in Verkehr gebracht werden

    Parallel dazu muss Deutschland ein nationales Durchführungsgesetz verabschieden. Der aktuelle Referentenentwurf des BMI sieht vor, dem BSI die zentrale Rolle als Marktüberwachungsbehörde, CSIRT und Beschwerdestelle zuzuweisen. TeleTrusT, der Bundesverband IT-Sicherheit, kritisiert in seiner aktuellen Stellungnahme vom 1. April 2026 allerdings, dass die personelle und finanzielle Ausstattung des BSI dafür nicht gesichert sei und die vorgesehenen Unterstützungsmaßnahmen für Unternehmen mit nur 1,28 Mio. Euro jährlich massiv unterfinanziert seien.

    Wen betrifft der CRA direkt?

    Hersteller

    Wer Produkte mit digitalen Elementen herstellt und in der EU in Verkehr bringt, ist Hauptadressat des CRA. Das betrifft nicht nur klassische Hardware-Hersteller, sondern ausdrücklich auch Softwareunternehmen. Selbst Open-Source-Projekte können unter bestimmten Voraussetzungen erfasst sein, wenn sie kommerziell genutzt werden.

    Importeure und Händler

    Wer Produkte aus Drittstaaten in die EU importiert oder weitervertreibt, muss sicherstellen, dass die CRA-Anforderungen erfüllt sind. Im Klartext: Wer IT-Produkte aus den USA, China oder anderen Nicht-EU-Staaten bezieht und im eigenen Geschäftsbetrieb einsetzt oder weiterverkauft, trägt Mitverantwortung.

    Anwender und Betreiber

    Unternehmen, die Produkte mit digitalen Elementen einsetzen, sind zwar nicht direkt Adressaten des CRA. Mittelbar betrifft sie der CRA aber erheblich — und genau hier wird es für die Kunden von NEOSEC relevant.

    Was der CRA für NEOSEC-Kunden konkret bedeutet

    1. Höhere Baseline-Sicherheit in der Lieferkette

    Der CRA wird dafür sorgen, dass Produkte, die in der EU verkauft werden, ein Mindestmaß an Cybersicherheit mitbringen. Für Betreiber kritischer Infrastrukturen und NIS2-pflichtige Unternehmen bedeutet das langfristig: Die Produkte, die Sie einkaufen, werden sicherer. Kurzfristig bedeutet es allerdings auch: Ihre bestehenden Beschaffungsprozesse müssen angepasst werden. Fragen Sie Ihre Lieferanten nach CRA-Konformität, SBOM und Schwachstellenmanagement-Prozessen.

    2. Wechselwirkung mit NIS2

    NIS2 verpflichtet Unternehmen zu Risikomanagementmaßnahmen — und dazu gehört ausdrücklich auch die Sicherheit in der Lieferkette (Art. 21 Abs. 2 lit. d NIS2-Richtlinie). Der CRA liefert hier das Pendant auf Produktseite. Wer als NIS2-pflichtige Einrichtung Produkte ohne CRA-Konformität einsetzt, könnte mittelfristig Schwierigkeiten bekommen, die eigenen Lieferkettensicherheitspflichten nachzuweisen. Umgekehrt wird die CRA-Konformität eines Produkts zu einem belastbaren Nachweis im Rahmen Ihres NIS2-Risikomanagements.

    3. Software Bill of Materials wird Standard

    Der CRA macht die SBOM — eine maschinenlesbare Aufstellung aller Softwarekomponenten eines Produkts — zur Pflicht. Für Ihr Schwachstellenmanagement ist das ein Gewinn: Wenn ein neues CVE veröffentlicht wird, können Sie anhand der SBOM Ihrer eingesetzten Produkte sofort prüfen, ob betroffene Komponenten in Ihrem Netz laufen. Voraussetzung dafür ist, dass Sie SBOMs Ihrer Lieferanten einfordern und systematisch auswerten — idealerweise automatisiert über Ihr SIEM.

    4. Meldepflichten ergänzen sich

    NIS2 verpflichtet Betreiber zur Meldung von Sicherheitsvorfällen. Der CRA verpflichtet Hersteller zur Meldung aktiv ausgenutzter Schwachstellen. Für Sie als Betreiber heißt das: Sie erfahren schneller von Schwachstellen in den Produkten, die Sie einsetzen. Gleichzeitig steigt die Anforderung, diese Informationen auch operativ zu verarbeiten — also zeitnah zu bewerten, zu priorisieren und zu patchen.

    5. Übergangszeit nutzen

    Bis Dezember 2027 gilt die volle Übergangsfrist. Diese Zeit sollten Unternehmen nutzen, um ihre Beschaffungsprozesse, Lieferantenanforderungen und das interne Schwachstellenmanagement auf den CRA vorzubereiten. Warten Sie nicht, bis Ihre Lieferanten von sich aus CRA-konforme Produkte liefern — setzen Sie die Anforderungen jetzt schon in Ihre Einkaufsbedingungen.

    Handlungsempfehlungen

    Für alle Unternehmen, die IT-Produkte einsetzen:

    • Inventar erstellen: Welche Produkte mit digitalen Elementen setzen Sie ein? Welche davon kommen von Herstellern außerhalb der EU?
    • Lieferantenanforderungen anpassen: Nehmen Sie CRA-Konformität, SBOM-Bereitstellung und definierte Supportzeiträume in Ihre Beschaffungsanforderungen auf
    • SBOM-Management aufbauen: Etablieren Sie Prozesse, um SBOMs Ihrer Lieferanten entgegenzunehmen, zu speichern und bei neuen CVEs automatisiert abzugleichen
    • Schwachstellenmanagement schärfen: Stellen Sie sicher, dass Ihr SOC oder SIEM die Herstellermeldungen zu Schwachstellen aufnehmen und priorisieren kann
    • NIS2-Dokumentation ergänzen: Die CRA-Konformität Ihrer eingesetzten Produkte wird ein wichtiger Baustein in Ihrer NIS2-Risikomanagement-Dokumentation

    Für Unternehmen, die selbst Produkte herstellen oder vertreiben:

    • CRA-Betroffenheit prüfen: Fallen Ihre Produkte unter den CRA? In welche Risikoklasse?
    • Security-by-Design verankern: Überprüfen Sie Ihre Entwicklungsprozesse — Cybersicherheit muss ab der Konzeptionsphase integriert sein
    • Schwachstellenmanagement-Prozess etablieren: 24-Stunden-Meldepflicht an die ENISA bei aktiv ausgenutzten Schwachstellen — das erfordert funktionierende interne Prozesse
    • SBOM generieren: Automatisieren Sie die Erstellung von Software Bills of Materials als Teil Ihrer CI/CD-Pipeline
    • Konformitätsbewertung vorbereiten: Klären Sie frühzeitig, ob eine Selbstbewertung ausreicht oder eine Prüfstelle hinzugezogen werden muss

    Was noch unklar ist

    Der CRA ist als EU-Verordnung unmittelbar anwendbar, benötigt aber nationale Durchführungsgesetze — und genau dort gibt es Nachholbedarf. Der aktuelle deutsche Referentenentwurf weist laut TeleTrusT erhebliche Lücken auf: Die Ausnahme von der Akkreditierungspflicht für Konformitätsbewertungsstellen ist zu weit gefasst, das geplante Reallabor für Cyberresilienz bleibt inhaltlich vage, und die finanzielle Ausstattung der Unterstützungsmaßnahmen für KMU ist unzureichend.

    Für Unternehmen bedeutet das: Planen Sie nicht mit dem Minimalstandard des Durchführungsgesetzes, sondern orientieren Sie sich direkt an den Anforderungen der EU-Verordnung selbst. Das nationale Gesetz wird nur den Vollzugsrahmen regeln — die materiellen Pflichten stehen bereits fest.

    Einordnung

    Der CRA ist neben NIS2 und der CER-Richtlinie der dritte große Baustein im EU-Cybersicherheitsrahmen. Während NIS2 die Betreiber adressiert und die CER-Richtlinie die physische Resilienz, schließt der CRA die Lücke auf Produktseite. Für Unternehmen, die bereits unter NIS2 fallen, ist der CRA keine zusätzliche Belastung, sondern eine sinnvolle Ergänzung: Er sorgt dafür, dass die Produkte, die Sie einsetzen, endlich den Sicherheitsstandards entsprechen müssen, die Sie selbst einhalten sollen.

    Ob der CRA in der Praxis funktioniert, wird maßgeblich davon abhängen, ob die Marktüberwachung durch das BSI tatsächlich wirksam wird — und ob Unternehmen die Übergangszeit nutzen, statt sie aussitzen.

    Sie möchten wissen, wie der CRA konkret auf Ihr Unternehmen wirkt und wie Sie Ihre NIS2-Compliance um die CRA-Dimension erweitern? NEOSEC unterstützt Sie bei der Gap-Analyse, der Bewertung Ihrer Lieferkette und der Integration in Ihr bestehendes Risikomanagement. Sprechen Sie uns an.

  • Axios Supply-Chain-Angriff: Was Admins jetzt prüfen müssen

    VonJ. Benjamin Espagné

    Am 31. März 2026 wurde das npm-Paket Axios — mit rund 100 Millionen wöchentlichen Downloads eine der meistgenutzten JavaScript-Bibliotheken weltweit — durch einen Supply-Chain-Angriff kompromittiert. Die trojanisierten Versionen waren nur zwei bis drei Stunden online, bevor sie entfernt wurden. Trotzdem: Bei dieser Verbreitung reicht ein kurzes Zeitfenster, um tausende Entwicklungsumgebungen zu infizieren.

    Google Threat Intelligence hat den Angriff der nordkoreanischen Gruppe UNC1069 zugeordnet. Es handelt sich nicht um einen opportunistischen Angriff, sondern um eine sorgfältig vorbereitete Operation mit plattformübergreifender Malware, Anti-Forensik-Mechanismen und mehrstufiger Verschleierung.

    Was passiert ist

    Die Angreifer kompromittierten den npm-Account des Hauptmaintainers von Axios und veröffentlichten zwei trojanisierte Versionen:

    • axios@1.14.1
    • axios@0.30.4

    Beide Versionen enthielten eine neue Abhängigkeit namens plain-crypto-js@4.2.1 — ein sogenanntes Phantom-Dependency: im Manifest gelistet, aber nirgends im eigentlichen Code verwendet. Dieses Paket enthielt einen verschleierten postinstall-Hook, der beim Installieren automatisch ein Dropper-Skript ausführte.

    Das Skript lud plattformspezifische RAT-Payloads (Remote Access Trojaner) nach:

    • macOS: Binary in /Library/Caches/com.apple.act.mond, Gatekeeper-Bypass via codesign, C2-Callback alle 60 Sekunden
    • Windows: PowerShell-Payload als %PROGRAMDATA%\wt.exe, Persistenz via Registry-Key „MicrosoftUpdate”
    • Linux: Python-Skript als /tmp/ld.py, ausgeführt via nohup

    Nach der Infektion löschte die Malware ihre Spuren: Das kompromittierte package.json wurde durch eine saubere Kopie ersetzt, die Version 4.2.0 statt 4.2.1 meldet. Ein npm list zeigt dann fälschlicherweise eine unbedenkliche Version an.

    Wer betroffen ist

    Potenziell betroffen ist jedes Projekt, das Axios als direkte oder transitive Abhängigkeit nutzt. Laut Wiz betrifft das rund 80 % aller Cloud- und Code-Umgebungen. Fast 175.000 npm-Pakete listen Axios als Dependency.

    Konkret betroffen sind Umgebungen, in denen zwischen dem 31. März (ca. 00:00 UTC) und ca. 03:00 UTC ein npm install, npm update oder ein CI/CD-Build ohne fixiertes Lockfile lief und dabei eine der beiden Versionen gezogen wurde.

    Umgebungen mit einem intakten package-lock.json oder yarn.lock, in denen im Zeitraum kein ungelockerter Install stattfand, sind mit hoher Wahrscheinlichkeit nicht betroffen.

    Sofortmaßnahmen für Admins

    1. Lockfiles und node_modules prüfen

    In jedem Node.js-Projekt auf allen Entwicklungs-, Build- und Produktionsservern:

    # Nach der Phantom-Dependency suchen
grep -r "plain-crypto-js" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

# Installierte Axios-Version prüfen
npm list axios 2>/dev/null | head -20

# In node_modules direkt suchen
find . -path '*/plain-crypto-js' -type d 2>/dev/null

    Wenn plain-crypto-js auftaucht oder Axios in Version 1.14.1 bzw. 0.30.4 installiert ist: Umgebung als kompromittiert betrachten.

    2. Systemweiter Scan — das gesamte Filesystem prüfen

    Die projektbezogene Suche in Schritt 1 findet nur bekannte Projektverzeichnisse. In der Praxis liegen node_modules auch in vergessenen Verzeichnissen, Temp-Ordnern, Backups oder gemounteten Shares. Deshalb: Einmal über das gesamte Filesystem scannen.

    macOS / Linux — Phantom-Dependency und RAT-Artefakte in einem Durchlauf:

    find / \( \
  -name "plain-crypto-js" -o \
  -path "*/com.apple.act.mond" -o \
  -name "ld.py" \
\) 2>/dev/null

    Windows (PowerShell) — Phantom-Dependency, RAT-Binary und Persistenz:

    # Phantom-Dependency im gesamten Filesystem suchen
Get-ChildItem -Path C:\ -Recurse -Directory -Filter "plain-crypto-js" -ErrorAction SilentlyContinue

# RAT-Binary prüfen
Test-Path "$env:PROGRAMDATA\wt.exe"

# Persistenz-Mechanismus in der Registry prüfen
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" -Name "MicrosoftUpdate" -ErrorAction SilentlyContinue

    Der find /-Scan dauert je nach Filesystem einige Minuten, ist aber der einzige Weg, um auch vergessene Installationen in Build-Caches, Docker-Volumes oder temporären Verzeichnissen zu finden. Auf Servern mit vielen gemounteten Filesystemen empfiehlt sich ein gezielter Scan pro Mount, um Netzwerk-Shares nicht doppelt zu durchsuchen.

    3. Kompromittierte Systeme isolieren — nicht bereinigen

    Infizierte Entwicklungsrechner und Build-Server sofort vom Netz nehmen. Nicht versuchen, die Malware manuell zu entfernen. Der RAT hat möglicherweise bereits Credentials exfiltriert. Stattdessen:

    • System isolieren und forensisch sichern
    • Von einem bekannt sauberen Snapshot oder Image neu aufsetzen
    • Erst nach dem Rebuild wieder ans Netz nehmen

    4. Credentials rotieren — alle

    Auf betroffenen Systemen gespeicherte Zugangsdaten als kompromittiert betrachten:

    • npm-Tokens
    • SSH-Schlüssel
    • Cloud-Provider-Keys (AWS, Azure, GCP)
    • CI/CD-Secrets (GitHub Actions, GitLab CI, Jenkins)
    • API-Keys und Service-Accounts
    • Datenbank-Zugangsdaten

    Wichtig: Nicht in-place rotieren. Alte Credentials widerrufen, neue auf sauberen Systemen generieren.

    5. CI/CD-Pipelines absichern

    # postinstall-Hooks in CI/CD-Builds deaktivieren
npm ci --ignore-scripts

# Danach nur gezielt Scripts ausführen, die bekannt sicher sind

    Zusätzlich: minimumReleaseAge in der npm-Konfiguration aktivieren. Diese Funktion blockiert die Installation von Paketen, die jünger als ein definierter Zeitraum sind — hätte in diesem Fall den Angriff verhindert, da plain-crypto-js weniger als 24 Stunden existierte.

    6. IOCs prüfen

    Netzwerk-Logs und Endpoint-Monitoring auf folgende Indikatoren prüfen:

    • Outbound-Verbindungen zu unbekannten Domains, die am 30./31. März registriert wurden
    • Prozesse namens com.apple.act.mond (macOS), wt.exe (Windows), ld.py (Linux)
    • Registry-Key HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate
    • Dateien in /Library/Caches/com.apple.act.mond

    Präventivmaßnahmen

    Lockfiles konsequent einsetzen

    package-lock.json bzw. yarn.lock sind keine optionale Bequemlichkeit, sondern die wichtigste Verteidigungslinie gegen Supply-Chain-Angriffe dieser Art. In CI/CD immer npm ci statt npm install verwenden — ersteres installiert exakt die im Lockfile festgeschriebenen Versionen.

    Trusted Publishing nutzen

    Beim Axios-Angriff war zwar OIDC Trusted Publishing für die 1.x-Linie konfiguriert, aber ein langlebiger Legacy-Token hatte Vorrang. Prüfen Sie für Ihre eigenen Pakete: Verwenden Sie ausschließlich kurzlebige OIDC-Tokens? Sind Legacy-Tokens widerrufen?

    Dependency-Monitoring etablieren

    Tools wie npm audit, Snyk, Socket oder Dependabot erkennen kompromittierte Pakete oft innerhalb von Minuten. Wer kein automatisches Monitoring hat, erfährt erst durch Zufall oder Medienberichte davon.

    Entwicklungsumgebungen härten

    Entwicklerrechner sind hochwertige Ziele, weil sie typischerweise SSH-Keys, Cloud-Credentials und Repository-Zugang bündeln. Segmentierung, Least-Privilege-Prinzipien und separate Build-Umgebungen reduzieren den Blast Radius erheblich.

    Erweiterte Angriffsfläche: KI-Tools

    Ein oft übersehener Aspekt: KI-gestützte Entwicklungstools wie Claude Code oder OpenAI Codex nutzen ebenfalls npm-Pakete und installieren diese teils automatisiert. Damit erweitert sich die Angriffsfläche über klassische Entwicklerumgebungen hinaus auf alle Arbeitsplätze, an denen solche Tools zum Einsatz kommen — auch bei Nicht-Entwicklern.

    Einordnung

    Dieser Angriff zeigt, wie fragil das Vertrauensmodell im npm-Ökosystem nach wie vor ist. Ein einziger kompromittierter Account — in diesem Fall der des Hauptmaintainers — reicht aus, um Schadcode in hunderttausende nachgelagerte Projekte zu schleusen. Die Attribution zu einer nordkoreanischen APT-Gruppe unterstreicht: Supply-Chain-Angriffe sind kein theoretisches Risiko, sondern ein aktiv genutzter Angriffsvektor staatlicher Akteure.

    Für Unternehmen, die Node.js-basierte Anwendungen entwickeln oder betreiben, ist die konsequente Absicherung der Software-Lieferkette keine Kür mehr — sie ist Pflicht. Wer ein SIEM betreibt, sollte die genannten IOCs in seine Detektionsregeln aufnehmen. Wer keins betreibt, hat ein grundsätzlicheres Problem.

    Sie wollen sicherstellen, dass Ihre Entwicklungs- und Produktionsumgebungen sauber sind? NEOSEC unterstützt Sie bei der forensischen Analyse, dem Incident Response und der nachhaltigen Absicherung Ihrer Software-Lieferkette. Sprechen Sie uns an.

  • MFA wird nicht gebrochen — sie wird umgangen. Und Ihre Mitarbeiter merken es nicht.

    VonJ. Benjamin Espagné

    Die Illusion der Sicherheit

    Multi-Faktor-Authentifizierung galt jahrelang als Goldstandard. Passwort gestohlen? Kein Problem — der Angreifer braucht noch den zweiten Faktor. Diese Annahme ist überholt.

    Adversary-in-the-Middle (AiTM) Phishing hat die Spielregeln verändert. Diese Angriffe stehlen nicht Passwort und MFA-Code getrennt. Sie fangen die gesamte Authentifizierung in Echtzeit ab — einschließlich des Session-Tokens, der beweist, dass ein Benutzer angemeldet ist.

    Der Mitarbeiter macht alles richtig: prüft auf HTTPS, bestätigt die MFA-Anforderung, vermeidet verdächtige Anhänge. Und wird trotzdem kompromittiert.

    Wie Adversary-in-the-Middle funktioniert

    Klassisches Phishing bedeutete schlampige Fake-Login-Seiten mit Tippfehlern. Diese Seiten konnten MFA nicht umgehen, weil sie keine Verbindung zum echten Authentifizierungsdienst hatten.

    Moderne Phishing-Seiten sind keine Fälschungen — sie sind Proxies. Tools wie Evilginx sitzen zwischen dem Benutzer und dem legitimen Dienst (Microsoft 365, Google Workspace, Okta) und leiten alles in Echtzeit weiter:

    • Der Mitarbeiter gibt sein Passwort ein → Es geht an Microsoft
    • Microsoft sendet die MFA-Challenge → Sie fließt über den Proxy zurück
    • Der Mitarbeiter bestätigt die MFA → Der Session-Cookie wandert zurück durch den Proxy
    • Der Angreifer nimmt den Session-Cookie, öffnet einen Browser auf einem völlig anderen Rechner — und ist drin

    Kein fehlgeschlagener Login-Versuch. Kein MFA-Fatigue-Bombing. Kein Brute-Force-Alert. Alles sieht normal aus, weil es technisch gesehen normal war. Die Authentifizierung war echt — der Angreifer hat nur zugesehen.

    Phishing-as-a-Service macht es zur Massenware

    Das ist längst keine Nation-State-Technik mehr. Phishing-as-a-Service-Plattformen wie Tycoon 2FA, Sneaky2FA und FlowerStorm haben AiTM-Angriffe zur Massenware gemacht. Laut Barracuda werden bis Ende 2026 über 90 Prozent aller Credential-Compromise-Angriffe auf ausgefeilte Phishing-Kits setzen. Die Zahl bekannter Kits hat sich 2025 verdoppelt.

    Man braucht keine Kenntnisse über Reverse Proxies. Man braucht eine Kreditkarte und ein Abonnement.

    Drei Gründe, warum Unternehmen scheitern

    1. Training für die falsche Bedrohung

    Die meisten Security-Awareness-Programme lehren immer noch: Achte auf Tippfehler, prüfe die Absenderadresse, fahre mit der Maus über Links. Das war für Phishing von 2015. Bei AiTM gibt es keine Tippfehler, weil die Seite echt ist. Das SSL-Zertifikat ist gültig. Der Login-Flow verhält sich wie erwartet. Laut Push Security wird inzwischen jeder dritte Phishing-Angriff außerhalb von E-Mail ausgespielt — über LinkedIn-DMs, Google-Suche oder Teams-Nachrichten.

    2. Blindes Vertrauen in Session-Cookies

    Sobald MFA abgeschlossen ist, behandeln die meisten Organisationen die resultierende Session als heilig. Aber Session-Cookies sind Bearer Tokens — wer sie hat, ist der authentifizierte Benutzer. Es gibt keine Bindung zwischen dem Cookie und dem Gerät, das ihn erzeugt hat. Kein Fingerprint. Kein Anker. Forschung von Silverfort zeigt: Selbst nach erfolgreicher FIDO2-Authentifizierung bleiben viele Identity Provider anfällig für Session-Hijacking.

    3. Reaktion auf Credential-Diebstahl, nicht Session-Diebstahl

    Incident-Response-Playbooks sind auf kompromittierte Passwörter ausgelegt: Reset erzwingen, Tokens widerrufen, MFA neu einrichten. Aber bei AiTM ist das Passwort nicht das Problem — die Session ist es. Wer nicht alle aktiven Sessions widerruft und auf Session Replay monitort, behebt die Kompromittierung nicht wirklich.

    Was wirklich hilft: Technische Gegenmaßnahmen

    1. FIDO2 / Passkeys deployen

    FIDO2-Security-Keys und Passkeys binden die Authentifizierung kryptografisch an die spezifische Domain. Kommt die Login-Anforderung von einer Proxy-Domain statt vom echten Dienst, verweigert der Key die Signatur. Das ist der einzige MFA-Mechanismus, der AiTM-Phishing strukturell blockiert.

    Wichtig: Proofpoint hat gezeigt, dass ein Downgrade-Angriff gegen FIDO in Microsoft Entra ID möglich ist, indem ein nicht unterstützter Browser vorgetäuscht wird. Daher: Fallback-Authentifizierungsmethoden deaktivieren, wo immer möglich.

    2. Sessions an Geräte binden (Device Compliance)

    Conditional Access Policies, die verwaltete, konforme Geräte erfordern, schaffen einen Hardware-Anker, den Cookie Replay nicht umgehen kann. Stiehlt jemand einen Session-Cookie und versucht, ihn von einem nicht verwalteten Gerät abzuspielen, wird die Session beendet. Das ist eine der wirksamsten Änderungen, die Organisationen implementieren können.

    3. Geo-Blocking und Country-Based Conditional Access

    Die meisten AiTM-Infrastrukturen operieren aus Regionen, aus denen Ihre Mitarbeiter nie arbeiten. Geo-basierte Conditional Access Policies können Authentifizierungen aus nicht-genehmigten Ländern blockieren oder zusätzliche Verifizierung erzwingen.

    In Microsoft Entra ID lässt sich das über Named Locations und Conditional Access umsetzen: Alle Anmeldungen aus Ländern außerhalb einer definierten Whitelist (z.B. Deutschland, Österreich, Schweiz) werden geblockt oder erfordern ein konformes Gerät. In Kombination mit Device Compliance entsteht ein doppelter Anker: richtiges Land UND richtiges Gerät.

    Einschränkung: Geo-Blocking basiert auf IP-Geolokation, die umgangen werden kann. Angreifer nutzen zunehmend Residential Proxies im Zielland, um Geo-Blocking zu umgehen. Daher ist Geo-Blocking eine nützliche Schicht, aber niemals die alleinige Verteidigung.

    4. Proxy- und VPN-Detection

    Da AiTM-Angriffe über Proxy-Infrastrukturen laufen, ist die Erkennung von Proxy-, VPN- und Tor-Verbindungen eine effektive Abwehrschicht. Mehrere Ansätze:

    • Microsoft Entra ID: Conditional Access kann Anmeldungen von anonymen IP-Adressen (Tor, anonyme Proxies) blockieren. Entra ID Protection erkennt “atypische Anmeldestandorte” und “unmögliche Reisen”
    • IP-Reputation-Services: Dienste wie IPQualityScore, MaxMind, Spur.us oder IPinfo bewerten IP-Adressen nach Risiko — Datacenter-IPs, bekannte Proxy-Provider, Residential-Proxy-Netzwerke
    • Reverse-Proxy-Fingerprinting: AiTM-Proxies hinterlassen Spuren — zusätzliche HTTP-Header, TLS-Fingerprint-Abweichungen (JA3/JA4-Hashes), minimale Latenz-Anomalien. Spezialisierte Anti-Phishing-Lösungen erkennen diese Muster
    • SIEM-Korrelation: Wenn eine erfolgreiche Authentifizierung von einer IP kommt, die als Proxy/VPN/Datacenter klassifiziert ist, und gleichzeitig von einem nicht-konformen Gerät erfolgt — ist das ein hochprioritärer Alert

    5. Session-Anomalie-Monitoring

    AiTM-Angriffe erzeugen keine fehlgeschlagenen Logins. Sie erzeugen perfekt aussehende erfolgreiche. Die Signale liegen in dem, was nach der Authentifizierung passiert:

    • Impossible Travel: Authentifizierungs-IP in München, nächste Aktivität 5 Minuten später aus Moskau
    • Neue MFA-Geräteregistrierung innerhalb von Minuten nach dem Login
    • Inbox-Rule-Erstellung: Angreifer erstellen E-Mail-Weiterleitungsregeln, um Evidenz zu verstecken
    • Massen-Downloads: SharePoint/OneDrive-Zugriffe in ungewöhnlichem Umfang
    • Token-Replay von neuer IP: Dieselbe Session taucht plötzlich von einer anderen IP auf

    6. Continuous Access Evaluation (CAE)

    Microsoft Continuous Access Evaluation ist ein Game-Changer: Statt Sessions bis zum Token-Ablauf laufen zu lassen, werden Änderungen (IP-Wechsel, Risikoerhöhung, Admin-Aktion) in Echtzeit an den Resource Provider kommuniziert. Eine gestohlene Session wird beim ersten IP-Wechsel sofort invalidiert — nicht erst nach einer Stunde.

    CAE ist in Microsoft 365 verfügbar und sollte zusammen mit Token Protection (Preview) aktiviert werden, das Session-Tokens kryptografisch an das Gerät bindet.

    7. Security Awareness neu denken

    Hören Sie auf, Mitarbeitern beizubringen, Phishing-Seiten zu erkennen — gegen moderne Angriffe können sie das nicht. Stattdessen eine einfache Regel:

    Wenn Sie den Login nicht selbst initiiert haben, indem Sie die URL direkt eingegeben haben — vertrauen Sie ihm nicht. Keine Login-Links in E-Mails klicken, auch wenn sie legitim aussehen. Login-Seiten bookmarken. Direkt navigieren.

  • CVE-2026-33017: Kritische Langflow-Schwachstelle wird innerhalb von Stunden ausgenutzt

    VonJ. Benjamin Espagné

    KI-Tooling als Einfallstor: Langflow im Fadenkreuz

    Die US-amerikanische Cybersecurity-Behörde CISA hat die Schwachstelle CVE-2026-33017 in ihren Known Exploited Vulnerabilities (KEV) Catalog aufgenommen und eine Patch-Frist bis zum 8. April 2026 gesetzt. Betroffen ist Langflow, eine weit verbreitete Open-Source-Plattform zur visuellen Erstellung von KI-Workflows und LLM-Agenten — mit über 60.000 GitHub-Stars und wachsender Verbreitung in Unternehmen.

    Die Schwachstelle hat einen CVSS-Score von 9.3 (kritisch) und ermöglicht es Angreifern, ohne Authentifizierung beliebigen Python-Code auf dem Server auszuführen. Das Bemerkenswerte: Die Ausnutzung begann innerhalb von 20 Stunden nach Bekanntwerden — ohne dass ein öffentlicher Exploit-Code existierte.

    Was ist Langflow — und warum wird es angegriffen?

    Langflow ist ein Open-Source-Framework, das es ermöglicht, LLM-Anwendungen (Large Language Models) visuell per Drag-and-Drop zu erstellen. Typische Einsatzgebiete sind RAG-Pipelines (Retrieval-Augmented Generation), KI-Agenten und Workflow-Automatisierungen.

    Die Plattform wird von Entwicklungsteams eingesetzt, die schnell KI-Prototypen und Produktionsworkflows aufbauen wollen. Viele Instanzen laufen auf Cloud-Servern — teilweise ohne ausreichende Absicherung oder hinter öffentlich erreichbaren Endpoints. Genau das macht sie zu einem attraktiven Ziel für automatisierte Angriffe.

    Technische Details: CVE-2026-33017

    Die Schwachstelle liegt im Endpoint build_public_tmp, der für öffentliche Flows konzipiert ist und absichtlich ohne Authentifizierung arbeitet. Das Problem: Der Endpoint akzeptiert vom Angreifer übermittelte Flow-Daten, die eingebetteten Python-Code enthalten können. Dieser Code wird ohne Sandboxing direkt auf dem Server ausgeführt.

    Laut der NVD-Beschreibung ist dies eine eigenständige Schwachstelle, die sich von CVE-2025-3248 unterscheidet. Letztere betraf den Endpoint /api/v1/validate/code und wurde durch das Hinzufügen einer Authentifizierung behoben. CVE-2026-33017 nutzt einen anderen Angriffsvektor über einen bewusst öffentlich zugänglichen Endpoint.

    Betroffen sind alle Langflow-Versionen bis 1.8.2. Das Update auf Version 1.9.0 behebt die Schwachstelle.

    20 Stunden vom Advisory zum Angriff

    Laut einem Bericht von Sysdig begannen Angreifer innerhalb von 20 Stunden nach Veröffentlichung des Advisories, verwundbare Langflow-Instanzen zu attackieren. Sysdig hatte Honeypot-Nodes mit verwundbaren Instanzen über mehrere Cloud-Provider verteilt und beobachtete vier Angriffsversuche innerhalb weniger Stunden nach Deployment.

    Ein Angreifer ging dabei über das initiale Scanning hinaus und exfiltrierte Umgebungsvariablen — einschließlich Zugangsdaten und API-Keys.

    Besonders alarmierend: Es existierte zum Zeitpunkt der ersten Angriffe kein öffentlicher Exploit-Code auf GitHub. Das Advisory selbst enthielt genügend Details — den verwundbaren Endpoint-Pfad und den Mechanismus zur Code-Injection über Flow-Node-Definitionen — um einen funktionierenden Exploit zu konstruieren.

    Einheitliches Angriffsmuster: os.popen() + HTTP-Exfiltration

    Sysdig identifizierte ein konsistentes Post-Exploitation-Playbook über alle beobachteten Angriffe hinweg:

    • Shell-Befehl über Pythons os.popen() ausführen
    • Output über HTTP an externe C2-Infrastruktur exfiltrieren
    • Umgebungsvariablen (Credentials, API-Keys) abgreifen

    Sysdig veröffentlichte zudem eine Liste von Indicators of Compromise (IOCs), darunter Angreifer-IPs, C2-Infrastruktur, Dropper-URLs und Interactsh-Callback-Domains.

    Warum Runtime Detection entscheidend ist

    Sysdig betont, dass bei derart schneller Ausnutzung klassische Patch-Zyklen nicht mehr ausreichen. Runtime Detection bleibt die primäre Verteidigungslinie. Die eingesetzten Erkennungsregeln benötigen keine spezifische Signatur für CVE-2026-33017, weil sie das Exploitation-Verhalten erkennen, nicht die Schwachstelle selbst. Dieselben Regeln greifen unabhängig davon, ob der initiale Zugang über CVE-2026-33017, CVE-2025-3248 oder eine andere RCE erfolgt.

    Das heißt: Verhaltensbasierte Erkennung erkennt den Angriff unabhängig von der spezifischen Schwachstelle — ob bekannt oder unbekannt.

    Was Unternehmen jetzt tun müssen

    • Sofort patchen: Update auf Langflow v1.9.0 oder höher
    • Exponierte Instanzen prüfen: Jede öffentlich erreichbare Langflow-Instanz als potenziell kompromittiert behandeln
    • Zugang einschränken: Langflow niemals ohne Authentifizierung und Netzwerksegmentierung betreiben
    • Umgebungsvariablen rotieren: Alle Credentials, API-Keys und Datenbankzugänge auf kompromittierten Systemen sofort wechseln
    • Runtime Monitoring: Verhaltensbasierte Erkennung implementieren, die Shell-Ausführung und HTTP-Exfiltration erkennt
    • IOCs prüfen: Sysdig-IOCs gegen eigene Logs abgleichen

  • APIs sind die neue Angriffsfläche — und die meisten Unternehmen sind blind

    VonJ. Benjamin Espagné

    Die Front hat sich verschoben

    „Wir haben früher über Defense-in-Depth und Endpoint Protection gesprochen. Dann kam Identity. Jetzt ist die API das neue Perimeter.“ So beschreibt Sean Murphy, CISO bei BECU, einem der größten US-Kreditinstitute, die aktuelle Lage. Und er steht mit dieser Einschätzung nicht allein.

    In einer aktuellen Erhebung von CSO Online berichten mehrere CISOs übereinstimmend: APIs haben Endpoints als primäre Angriffsfläche abgelöst. Sie sind die Eingangstür zu Backend-Systemen, Partnerschnittstellen und Kundendaten — und in vielen Unternehmen weder inventarisiert noch ausreichend geschützt.

    Die Zahlen: Jede dritte Organisation betroffen

    Ein Salt Security Report von 2025 zeigt:

    • Jede dritte Organisation wurde in den letzten 12 Monaten über eine API kompromittiert
    • 95 % der API-Angriffe kommen von authentifizierten Quellen — über gestohlene API-Keys oder Credentials

    Laut einer Studie von Enterprise Management Associates haben rund 70 % der Unternehmen nur 30 % ihrer APIs dokumentiert. Der Rest? Shadow-APIs, die außerhalb jeder Sicherheits-Governance existieren.

    Konservative Schätzungen gehen davon aus, dass ein Großunternehmen zwischen 250 und 500 APIs betreibt. In der Realität sind es oft Tausende.

    Warum EDR und WAF versagen

    Das Kernproblem: Traditionelle Sicherheitswerkzeuge wie EDR, XDR und WAF sind für API-Angriffe schlicht nicht gebaut. Sie erkennen Malware auf Endpoints und einfache Web-Exploits — aber API-Missbrauch sieht für diese Systeme wie normaler, valider Traffic aus.

    Elliott Franklin, CISO bei Fortitude Re, bringt es auf den Punkt: EDR und WAFs wurden für die Probleme von gestern gebaut. Ohne ein tiefes Verständnis von Business Logic und Identity Context übersehen traditionelle Tools Credential Stuffing, Token-Diebstahl oder Data Scraping.

    API-Angriffe nutzen keine Payload-Patterns, die eine WAF erkennen würde. Sie missbrauchen Business Logic: gebrochene Authentifizierung, übermäßig permissive Autorisierung, exzessive Datenexposition. Einzeln betrachtet sind die Requests valide — erst in der Sequenz entsteht der Angriff.

    James Faxon, Principal Advisor bei der Risk & Insight Group, erklärt: Ein Angreifer braucht keinen Laptop zu kompromittieren und keine Malware zu deployen. Mit einem gestohlenen Token und einer fehlerhaften Autorisierungslogik kann er sich lateral bewegen und Daten extrahieren, ohne traditionelle Endpoint-Controls auszulösen.

    KI verschärft das Problem — auf beiden Seiten

    Chaim Mazal, Chief AI and Security Officer bei Gigamon, warnt: KI hat die Demokratisierung offensiver Tools ermöglicht. Jeder kann jetzt API-Schwachstellen ausnutzen, unabhängig vom Skill-Level — ohne eine einzige Zeile Code zu schreiben.

    Gleichzeitig vergrößert KI die Angriffsfläche von innen: Agentic AI, die autonom über APIs mit Systemen interagiert — einschließlich Model Context Protocol (MCP), Agent-to-Agent-Workflows und automatisierter Integrationen — schafft neue, schwer kontrollierbare Zugriffspfade.

    Eine Studie von Software Finder (2025) zeigt: 56 % der IT-Entscheider erwarten, dass ihr Software-Stack bis 2030 KI-gesteuert sein wird. Mehr KI bedeutet mehr API-Aufrufe, mehr nicht-menschliche Identitäten, mehr Angriffsfläche.

    Die Lieferkette als API-Risiko

    Laut Gartner nutzen 71 % der Unternehmen APIs von Drittanbietern — SaaS-Plattformen, Cloud-Dienste, Partner-Integrationen. Jede dieser Verbindungen ist ein potenzieller Angriffsvektor.

    Patrick Opet, CISO von JPMorganChase, veröffentlichte 2025 einen offenen Brief, in dem er warnte, dass das SaaS-Modell „stillschweigend Cyber-Angreifer ermöglicht“ und eine „substanzielle Schwachstelle schafft, die das globale Wirtschaftssystem schwächt“.

    In der Praxis heißt das: API-Keys und Tokens landen in Repositories, werden nicht rotiert, haben übermäßige Berechtigungen und sind teilweise offen im Web auffindbar. Escape entdeckte 2024 über 18.000 API-Secrets und Tokens im offenen Internet.

    Was CISOs empfehlen

    1. API-Inventar aufbauen

    „Was man nicht sieht, kann man nicht schützen“, sagt Andreas Gaetje, CISO bei Körber. Der erste Schritt ist ein vollständiges Inventar aller APIs — intern, extern, und von Drittanbietern. Jede API braucht einen Owner, eine Dokumentation und eine Threat-Model-Bewertung.

    2. API Governance einführen

    BECU implementierte eine einheitliche API-Policy für alle Entwickler — noch bevor die Technologie ausgerollt wurde. Jeder API-Builder unterliegt derselben internen Richtlinie. Das reduziert Fehlkonfigurationen, die laut OWASP Top 10 das größte API-Risiko darstellen.

    3. Identity-basierte Absicherung

    APIs als „nicht-menschliche Identitäten“ behandeln: Least-Privilege-Prinzip, zeitgebundene RBAC, regelmäßige Token-Rotation. Fortitude Re integriert API-Sicherheit direkt in die IAM-Strategie und trackt aktiv nicht-menschliche Identitäten.

    4. Security in die CI/CD-Pipeline

    API-Spezifikationen müssen automatisierte Sicherheitsvalidierung durchlaufen, bevor sie deployed werden. Infinite Computer Solutions hat Security-Checks direkt in die CI/CD-Pipeline eingebettet.

    5. Verhaltensbasiertes Runtime-Monitoring

    Wenn ein API-Consumer außerhalb seines erwarteten Musters agiert, ist das ein Security Event, keine technische Anomalie. Runtime-Erkennung ist die einzige Verteidigung, die bei Zero-Day-Exploitation funktioniert.

    6. Third-Party-APIs wie Risiken behandeln

    Credentials von Drittanbietern zentralisieren und verschlüsseln. Niemals rohe API-Keys an Entwicklungsteams verteilen. Regelmäßig rotieren und auf Behavioral Drift überwachen.

  • Supply-Chain-Angriffe: Wenn die Lieferkette zum Einfallstor wird

    VonJ. Benjamin Espagné

    Wenn der Zulieferer zum Einfallstor wird

    Ende Mai 2025 wurde Adidas Opfer eines Datenlecks — nicht über die eigenen Systeme, sondern über einen Dienstleister. Kundendaten gelangten in die Hände von Cyberkriminellen, weil ein Drittanbieter kompromittiert wurde. Der Fall ist kein Einzelfall, sondern Symptom eines systemischen Problems: Die digitale Lieferkette ist zum bevorzugten Angriffsvektor geworden.

    Das Handelsblatt berichtete am 25. März 2026 unter dem Titel „Attacke durch die Hintertür” ausführlich über die wachsende Bedrohung durch Supply-Chain-Angriffe. Die Zahlen sind alarmierend — und sie bestätigen, was wir bei NEOSEC seit Jahren in der Praxis sehen.

    Die Zahlen sprechen eine klare Sprache

    Laut dem Global Incident Response Report von Palo Alto Networks haben sich Supply-Chain-Attacken seit 2022 um das 3,8-Fache erhöht und machen mittlerweile 23 Prozent aller Angriffe aus. Eine Studie des Branchenverbands Bitkom zeigt: Fast jedes zehnte deutsche Unternehmen (9 %) weiß, dass eigene Zulieferer in den vergangenen zwölf Monaten Opfer von Cyberangriffen wurden. Weitere 19 Prozent hatten zumindest einen Verdachtsfall.

    Die Europäische Agentur für Cybersicherheit (ENISA) stuft Supply-Chain-Kompromittierungen in ihrem aktuellen Threat Landscape Report als eine der Top-Bedrohungen ein. Das BSI bestätigt im Lagebericht zur IT-Sicherheit in Deutschland 2024, dass Angriffe über die Lieferkette ein zunehmendes Risiko für die deutsche Wirtschaft darstellen — insbesondere für kritische Infrastrukturen und deren Zulieferer.

    Und die Konsequenzen? Laut Bitkom erlitten 41 Prozent der betroffenen Unternehmen Produktionsausfälle, Lieferengpässe oder Reputationsschäden.

    Der Dominoeffekt: Warum ein Angriff viele trifft

    Christoph Demiriz, Geschäftsführer von Digital Recovery, bringt es auf den Punkt: Angriffe auf Unternehmen in der Lieferkette sind für Cyberkriminelle strategisch besonders attraktiv, weil sie einen Dominoeffekt erzeugen.

    Die Logik dahinter ist einfach: Wenn ein IT-Dienstleister, ein Softwareanbieter oder ein Managed-Service-Provider kompromittiert wird, sind potenziell Dutzende oder Hunderte seiner Kunden betroffen — gleichzeitig. Zwei Beispiele illustrieren das:

    • Ein Systemhaus in Schleswig-Holstein, das die IT von rund 30 Unternehmen betreute, wurde über einen Update-Mechanismus kompromittiert. Angreifer konnten Schadsoftware bei mehreren Kunden gleichzeitig einschleusen und zentrale Systeme verschlüsseln.
    • Ein kommunaler Dienstleister in Südwestfalen wurde angegriffen — über 100 Städte und Gemeinden in Nordrhein-Westfalen waren betroffen. IT-Dienste, Websites und Telefonanlagen fielen aus. Die Bearbeitung von Bürgeranträgen verzögerte sich teilweise um mehrere Monate.

    Diese Fälle stehen in einer Reihe mit den großen Supply-Chain-Angriffen der letzten Jahre: SolarWinds (2020), Kaseya (2021) und die MOVEit-Schwachstelle (2023) zeigten auf globaler Ebene, wie verheerend ein einziger kompromittierter Dienstleister sein kann.

    NIS2 macht Lieferkettensicherheit zur Pflicht

    Die EU hat reagiert. Mit der NIS2-Richtlinie — in Deutschland umgesetzt durch das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz (NIS2UmsuCG) — wird Lieferkettensicherheit erstmals explizit zur gesetzlichen Pflicht.

    Artikel 21 der NIS2-Richtlinie verlangt von Unternehmen unter anderem:

    • Sicherheit der Lieferkette — einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen Unternehmen und ihren unmittelbaren Anbietern oder Diensteanbietern
    • Risikobewertung der IT-Sicherheit von Zulieferern und Dienstleistern
    • Meldepflichten — 24 Stunden für die Erstmeldung, 72 Stunden für den Detailbericht ans BSI
    • Persönliche GF-Haftung bei Nichteinhaltung

    IT-Rechtsanwalt Jens Ferner betont: Die Richtlinie verlangt verhältnismäßige Maßnahmen, über die Unternehmen selbst entscheiden müssen. Eine Untersuchung aller technischen Einrichtungen sei nicht erforderlich — aber die Unternehmen müssen nachweisen können, dass sie ihre Lieferkette im Blick haben.

    Wer das nicht tut, riskiert Bußgelder bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes — je nachdem, was höher ist.

    Was Unternehmen jetzt tun müssen

    Die Empfehlungen aus verschiedenen Quellen — BSI, ENISA, und unserer eigenen Praxis bei NEOSEC — konvergieren auf dieselben Kernmaßnahmen:

    1. Sichtbarkeit schaffen

    Wer nicht sieht, kann nicht erkennen. Wer nicht erkennt, kann nicht reagieren. Ein zentrales SIEM-System erfasst alle sicherheitsrelevanten Ereignisse — auch die, die über Schnittstellen zu Dienstleistern und Zulieferern hereinkommen. Ohne SIEM gibt es keine nachweisbare Erkennung, ohne Erkennung keinen NIS2-konformen Nachweis.

    2. Netzwerksegmentierung

    Wenn ein Zulieferer-Zugang kompromittiert wird, darf der Schaden nicht das gesamte Netz betreffen. Klare Netzwerksegmentierung begrenzt die Ausbreitung — im IT- wie im OT-Bereich.

    3. Lieferanten-Audits

    Lassen Sie sich die Sicherheitsmaßnahmen Ihrer Partner konkret nachweisen. Nicht mit einem Fragebogen, sondern mit technischen Nachweisen: Penetrationstests, SIEM-Logs, Incident-Response-Pläne, ISO-27001-Zertifizierungen.

    4. Backup- und Wiederanlaufstrategie

    Notfallkonzepte müssen regelmäßig getestet werden — nicht nur dokumentiert. Viele Firmen verfügen zwar über Datensicherungen, sind jedoch nicht in der Lage, diese im Ernstfall in der erforderlichen Geschwindigkeit einzusetzen.

    5. Meldeketten etablieren

    Die 24h/72h-Meldepflicht der NIS2 lässt keinen Spielraum für Improvisation. Wer im Ernstfall erst klären muss, wen er anruft, hat bereits verloren.

  • Wenn die Firewall selbst zur Sicherheitslücke wird — Was CVE-2026-20131 für Ihr Unternehmen bedeutet

    VonJ. Benjamin Espagné

    Es gibt Cyberangriffe, die einen innehalten lassen. CVE-2026-20131 ist so einer. Denn diesmal sitzt die Schwachstelle nicht in einer veralteten Anwendung, nicht in einem vergessenen System im Keller des Rechenzentrums — sondern direkt im Herz der Netzwerksicherheit: im Management-Interface von Cisco Secure Firewall.

    Die amerikanische Bundesbehörde für Cybersicherheit CISA hat in dieser Woche einen dringenden Warnhinweis herausgegeben. Die Lücke wird aktiv ausgenutzt. Nicht theoretisch. Nicht in Proof-of-Concept-Demos. Sondern in echten Ransomware-Angriffen gegen echte Unternehmen — jetzt, gerade, während Sie diese Zeilen lesen.

    Was passiert technisch — und warum es so gefährlich ist

    Das Cisco Secure Firewall Management Center ist das Werkzeug, mit dem IT-Teams ihre Firewall-Infrastruktur zentral steuern und überwachen. Genau dieses Interface hat eine Schwachstelle in der Art, wie es eingehende Datenpakete verarbeitet.

    Die Lücke erlaubt es einem Angreifer, über das öffentlich erreichbare Management-Interface eigenen Code einzuschleusen und auszuführen — mit vollen Systemrechten. Das Fatale: Es wird dafür kein gültiges Passwort, keine Zugangsdaten, keine vorherige Authentifizierung benötigt. Wer das Management-Interface aus dem Internet erreichen kann, kann angreifen.

    Mit vollen Administratorrechten auf dem Firewall-Management kann ein Angreifer Sicherheitsregeln deaktivieren oder gezielt umschreiben, Protokollierung und Alarmierung abstellen — der Einbruch bleibt unsichtbar —, den eigentlichen Ransomware-Angriff auf das dahinterliegende Netzwerk vorbereiten und sich dauerhaft im System festsetzen, bevor irgendjemand Alarm schlägt.

    Wer Kontrolle über das Firewall-Management hat, hat im Wesentlichen Kontrolle über die gesamte Netzwerksicherheit des Unternehmens.

    Betroffen: Cisco Secure Firewall Management Center und Security Cloud Control

    Konkret betroffen sind Unternehmen, die Cisco Secure Firewall Management Center (FMC) in verschiedenen Versionen sowie Cisco Security Cloud Control einsetzen. Cisco ist eines der weltweit meistgenutzten Netzwerk- und Sicherheitsunternehmen — entsprechend groß ist die Angriffsfläche.

    Die eigentliche Botschaft: Prävention versagt — Detektion ist alles

    Viele Sicherheitsstrategien bauen auf dem Prinzip auf: Wenn wir die Firewall richtig konfigurieren, sind wir sicher. CVE-2026-20131 zeigt einmal mehr, dass dieses Prinzip allein nicht ausreicht.

    Eine Zero-Day-Lücke ist per Definition eine Schwachstelle, für die es zum Zeitpunkt der Angriffe noch keinen Patch gibt oder die so neu ist, dass viele Systeme noch ungepacht sind. Auch nach Bekanntwerden dauert das vollständige Einspielen von Patches in verteilten Unternehmensinfrastrukturen oft Tage bis Wochen.

    Die entscheidende Frage lautet deshalb nicht: „Haben wir eine Firewall?” — sondern: „Merken wir, wenn jemand unsere Firewall bereits kompromittiert hat?”

    Hier kommen API-Sicherheitslösungen wie Neosec eine zentrale Rolle zu. Moderne Angriffe — inklusive solcher, die über Management-Interfaces laufen — hinterlassen Spuren im API-Traffic. Ungewöhnliche Anfragen. Zugriffsmuster, die von normalen Administrationsmustern abweichen. Befehle, die zu ungewöhnlichen Zeiten ausgeführt werden. Wer diese Anomalien in Echtzeit erkennt, kann handeln, bevor der eigentliche Schaden entsteht.

    Was jetzt zu tun ist

    Sind wir betroffen? Setzen wir Cisco Secure Firewall Management Center oder Cisco Security Cloud Control ein? Wenn ja, ist sofortiges Handeln angezeigt. Cisco hat Sicherheitshinweise und — sofern verfügbar — Patches herausgegeben.

    Ist das Management-Interface aus dem Internet erreichbar? Jedes Firewall-Management-Interface, das direkt aus dem öffentlichen Internet erreichbar ist, vergrößert die Angriffsfläche massiv. Die Best Practice: Management-Zugang ausschließlich über VPN oder isolierte Management-Netzwerke.

    Haben wir Monitoring auf ungewöhnliches Verhalten? Nicht jede Attacke lässt sich verhindern. Aber jede Attacke hinterlässt Spuren — wenn man hinsieht. Stellen Sie sicher, dass Ihre Sicherheitsinfrastruktur Anomalien im API- und Management-Traffic aktiv überwacht und alarmiert.

    Was ist unser Incident-Response-Plan? Wenn ein Angriff über diesen Vektor stattgefunden hat — wer wird informiert? Wer entscheidet über Gegenmaßnahmen? Diese Fragen sollten nicht erst im Ernstfall beantwortet werden.

    Fazit

    CVE-2026-20131 ist kein Einzelfall. Es ist ein weiteres Kapitel in einer langen Geschichte von Schwachstellen in genau den Systemen, denen wir am meisten vertrauen. Perimeter-Sicherheit allein ist seit Jahren nicht mehr ausreichend.

    Unternehmen, die heute resilient gegenüber solchen Angriffen sind, haben eines gemeinsam: Sie gehen davon aus, dass Angreifer möglicherweise bereits im Netzwerk sind. Sie investieren in Detektion, Sichtbarkeit und die Fähigkeit, schnell zu reagieren — nicht nur darin, den Einbruch zu verhindern.

    Neosec hilft dabei, genau diese Sichtbarkeit herzustellen — besonders dort, wo moderne Angriffe ansetzen: in den APIs und Management-Interfaces, über die heute Infrastruktur gesteuert wird.

    Sprechen Sie uns an. Sicherheit beginnt damit, zu wissen, was gerade in Ihrem Netzwerk passiert.

    Quellen: CISA Advisory zu CVE-2026-20131, Cisco Security Advisory (März 2026)

Keine weiteren News.

Keine weiteren News.

Sicherheitslücken schließen. Risiken senken. Jetzt handeln!

Unsere Experten zeigen Ihnen live, wie wir Angriffe erkennen, stoppen und Ihr Unternehmen schützen.

Blog

Aktuelle Sicherheitsereignisse