• 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)

  • KI beschleunigt Exploits – die Lücke zwischen Bekanntwerden und Angriff schrumpft drastisch

    VonJ. Benjamin Espagné

    Künstliche Intelligenz verändert die Sicherheitslandschaft in einem Tempo, dem viele Unternehmen nicht folgen können. Aktuelle Analysen des SANS Institute zeigen: KI beeinflusst nicht nur die Verteidigung, sondern vor allem das Timing von Angriffen. Der Zeitraum zwischen der öffentlichen Bekanntgabe einer Schwachstelle und ihrer ersten aktiven Ausnutzung verkürzt sich von Wochen auf Stunden oder Minuten.

    Von Disclosure zu Exploit: Das Zeitfenster schrumpft

    Das klassische Sicherheitsmodell basiert auf einem Ablauf: Schwachstelle wird bekannt → Hersteller veröffentlicht Patch → Unternehmen spielt Patch ein → System ist geschützt. Dieses Modell funktionierte, solange zwischen Disclosure und Exploitation Wochen oder Monate lagen.

    KI verändert diese Gleichung fundamental. Sobald technische Details zu einer Schwachstelle verfügbar sind — sei es durch ein Advisory, einen CVE-Eintrag oder einen Commit in einem Open-Source-Repository — können KI-gestützte Systeme automatisiert Exploit-Code generieren. Die manuelle Analyse durch einen erfahrenen Exploit-Entwickler, die früher Tage dauerte, wird durch LLMs auf Stunden oder Minuten komprimiert.

    Ein konkretes Beispiel: Die Langflow-Schwachstelle CVE-2026-33017 wurde innerhalb von 20 Stunden nach Veröffentlichung des Advisories aktiv ausgenutzt — ohne dass ein öffentlicher Exploit existierte. Das Advisory allein enthielt genug Information, um einen funktionierenden Exploit zu konstruieren.

    Fast-Flux-Netzwerke: Dynamische Angriffs-Infrastruktur

    Parallel zur KI-beschleunigten Exploit-Entwicklung warnt die NSA gemeinsam mit internationalen Partnern vor der zunehmenden Nutzung sogenannter Fast-Flux-Netzwerke. Dabei wechseln Angreifer IP-Adressen und DNS-Zuordnungen extrem schnell, um Command-and-Control-Server, Exploit-Infrastruktur und Malware-Verteilung zu verschleiern.

    Die NSA stuft Fast-Flux inzwischen als nationale Sicherheitsbedrohung ein. Besonders kritisch: Staatlich unterstützte Akteure und organisierte Cybercrime-Gruppen nutzen diese Technik, weil sie Erkennung, Attribution und Abschaltung erheblich erschwert.

    In Kombination mit KI-gestützter Schwachstellenanalyse entsteht eine neue Dynamik: Automatisierte Systeme generieren Exploits, bauen dynamische Infrastruktur auf und führen Angriffe nahezu in Echtzeit durch — schneller als jeder manuelle Patch-Zyklus reagieren kann.

    Warum klassische Verteidigungsmodelle versagen

    Drei strukturelle Defizite werden sichtbar:

    • Reaktive Sicherheitsmodelle: Das Muster „Disclosure → Bewertung → Patch → Monitoring” funktioniert nicht mehr, wenn Angriffe beginnen, bevor ein Patch verfügbar ist oder eingespielt werden kann
    • Statische Erkennung: Fast-Flux-Netzwerke umgehen statische Blocklisten, klassische IOC-Feeds und einfache DNS-Filter. Ohne verhaltensbasierte Erkennung bleiben diese Aktivitäten unsichtbar
    • Manuelle Reaktion: Wenn der Angriff automatisiert ist, muss auch die Verteidigung automatisiert sein. Alarme, die erst am nächsten Morgen gesichtet werden, kommen zu spät

    Handlungsempfehlungen

    • Automatisierte Schwachstellenkorrelation: Neue CVEs müssen unmittelbar mit eigener Telemetrie, Threat Intelligence und Exposure-Daten abgeglichen werden — ohne manuelle Verzögerung
    • DNS-Anomalie-Erkennung: Schnelle IP-Rotationen, verdächtige DNS-Auflösungen und ungewöhnliche Kommunikationsmuster aktiv überwachen, um Fast-Flux-Netze frühzeitig zu identifizieren
    • Proaktive Abwehr statt Patch-Abhängigkeit: Virtuelle Patches, Netzwerksegmentierung und adaptive Zugriffskontrollen müssen bereits greifen, bevor ein offizielles Update verfügbar ist
    • SIEM mit Verhaltensanalyse: Signaturbasierte Erkennung reicht nicht mehr. Verhaltensbasierte Regeln erkennen Exploitation-Muster unabhängig von der spezifischen CVE
    • 24/7-Monitoring: Wenn Angreifer in Minuten zuschlagen, kann die Erkennung nicht bis zum nächsten Arbeitstag warten

  • Moin Dr. Anatolii Nazarko – Security Analyst & Head of Research bei Neosec

    VonJ. Benjamin Espagné

    Seit dem 1. September 2025 verstärkt Dr. rer. nat. Anatolii Nazarko das Team von Neosec als Security Analyst & Head of Research bei Neosec.

    Mit seiner außergewöhnlichen Kombination aus wissenschaftlicher Präzision, analytischer Tiefe und praktischer Cyberabwehr-Erfahrung bringt er neue Impulse in den Bereich der Sicherheitsforschung und operativen Bedrohungserkennung.

    Dr. Nazarko ist promovierter Physiker der Technischen Nationaluniversität der Ukraine (KPI) und blickt auf mehr als 15 Jahre Erfahrung in Datenanalyse, Machine Learning, mathematischer Modellierung und automatisierter Detektionzurück.

    Vor seinem Wechsel zu Neosec war er u. a. bei Welltech Apps Limited, Maverixtech und Auroratechnologies tätig, wo er komplexe Datenströme analysierte, prädiktive Modelle entwickelte und die Integration von KI in sicherheitsrelevante Systeme verantwortete. Seine Arbeit reichte von der Segmentierung von Nutzerverhalten bis hin zu Echtzeit-Analysen und automatisierten Entscheidungsmodellen – Kompetenzen, die heute zentral für die Weiterentwicklung moderner MDR-Lösungen sind.

  • Neue “Erfahrungen”: Adobe Experience Manager schafft es in die Hall of Shame

    VonJ. Benjamin Espagné

    Die CISA hat am 15. Oktober 2025 eine kritische Sicherheitslücke in Adobe Experience Manager (AEM) in ihren Known Exploited Vulnerabilities (KEV)-Katalog aufgenommen. CVE-2025-54253 erlaubt Remote Code Execution (RCE) über eine fehlerhafte Konfiguration in der Administrationsoberfläche von AEM Forms on JEE — mit einem CVSS-Score von 10.0, der höchstmöglichen Bewertung.

    Betroffene Versionen und Patch-Status

    Betroffen sind AEM-Versionen 6.5.23.0 und älter. Adobe stellte bereits im August 2025 ein außerplanmäßiges Update bereit, nachdem ein Proof-of-Concept öffentlich geworden war. Mit der Aufnahme in den KEV-Katalog setzt die CISA nun eine verbindliche Patch-Frist bis zum 5. November 2025 für US-Bundesbehörden. Für alle anderen Organisationen gilt: Die aktive Ausnutzung ist bestätigt — Patchen ist keine Option, sondern Pflicht.

    2.700+ produktive AEM-Installationen in Deutschland

    Laut BuiltWith setzen über 2.700 produktive Websites in Deutschland auf AEM — darunter DAX-Konzerne aus der Automobil-, Industrie-, Energie- und Finanzbranche. Zu den bekannten Nutzern gehören BMW, Mercedes-Benz, Volkswagen, SAP, Allianz, Fresenius, E.ON, DHL, Toyota und Philips. Weitere 3.000+ Domains befinden sich in der Implementierungsphase — darunter Porsche SE.

    Die Verbreitung macht AEM zu einem High-Value-Target: Ein einzelner Exploit kann potenziell tausende Unternehmen treffen.

    AEM als Angriffsfläche: Mehr als ein CMS

    Die Schwachstelle ist besonders kritisch, weil AEM in vielen Unternehmen nicht isoliert läuft. Als zentrale Content-Management-Plattform ist AEM typischerweise mit Backend-Systemen integriert:

    • SAP für Produktdaten und E-Commerce
    • Salesforce für Kundendaten und CRM
    • Azure AD / Entra ID für Authentifizierung
    • Interne APIs für Personalisierung und Analytics

    Ein erfolgreicher RCE-Angriff auf AEM kann daher weit über die Website hinausgehen: vollständige Systemkompromittierung, Zugriff auf Backend-Daten und laterale Bewegung ins Unternehmensnetz sind realistische Szenarien.

    Serie kritischer AEM-Schwachstellen

    CVE-2025-54253 reiht sich in eine Serie kritischer AEM-Schwachstellen ein:

    • CVE-2025-49533: Server-Side Request Forgery (SSRF) in AEM
    • CVE-2025-54254: Authentifizierungs-Bypass in AEM Forms

    Dass Adobe innerhalb weniger Monate mehrere kritische Schwachstellen in AEM patchen musste, deutet auf systematische Sicherheitsprobleme in der Plattform hin — und erhöht den Druck auf AEM-Betreiber, ihre Installationen regelmäßig zu aktualisieren und zu härten.

    Handlungsempfehlungen

    • Sofort patchen: Alle AEM-Instanzen auf eine Version nach 6.5.23.0 aktualisieren
    • AEM Forms on JEE härten: Administrationsoberflächen dürfen nicht aus dem Internet erreichbar sein. Zugriff nur über VPN oder dedizierte Management-Netzwerke
    • Netzwerksegmentierung prüfen: AEM-Server von Backend-Systemen (SAP, CRM, AD) durch Firewalls und Zugriffsregeln trennen
    • Web Application Firewall: WAF-Regeln für bekannte AEM-Exploit-Pfade aktivieren
    • SIEM-Monitoring: AEM-Server-Logs auf verdächtige Anfragen an die Administrationsoberfläche, ungewöhnliche Prozesse und ausgehende Verbindungen überwachen
    • Compromise Assessment: Wenn AEM vor dem Patch aus dem Internet erreichbar war, auf Kompromittierungsindikatoren prüfen

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