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

  • · ·

    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. 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

    3. 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.

    4. 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.

    5. 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
  • ·

    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)

  • · ·

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

    VonJ. Benjamin Espagné

    Die US-Behörde CISA (Cybersecurity and Infrastructure Security Agency) hat am 15. Oktober 2025 eine kritische Sicherheitslücke in Adobe Experience Manager (AEM) in ihren Known Exploited Vulnerabilities (KEV)-Katalog aufgenommen. Die Schwachstelle mit der Kennung CVE-2025-54253 erlaubt Remote-Code-Execution (RCE) über eine fehlerhafte Konfiguration in der Administrationsoberfläche von AEM Forms on JEE – CVSS-Score 10.0, also maximal kritisch.

    Betroffen sind AEM-Versionen 6.5.23.0 und älter. Adobe hatte bereits im August 2025 ein außerplanmäßiges Update bereitgestellt, nachdem ein Proof-of-Concept öffentlich geworden war. CISA setzt nun eine verbindliche Patch-Frist bis zum 5. November 2025.

    Neosec hat ermittelt: Laut BuiltWith setzen über 2.700 produktive Websites in Deutschland auf AEM – darunter große Konzerne aus der Automobil-, Industrie-, Energie- und Finanzbranche. Zu den bekannten AEM-Nutzern zählen BMW, Mercedes-Benz, Volkswagen, SAP, Allianz, Fresenius, E.ON, DHL, Toyota, Philips und viele andere. BuiltWith verzeichnet zudem mehr als 3.000 weitere Domains, bei denen AEM bereits in der Implementierungsphase ist – darunter Porsche SE.

    Die Lücke reiht sich ein in eine Serie kritischer AEM-Schwachstellen (u. a. CVE-2025-49533, CVE-2025-54254) und betrifft insbesondere Umgebungen, in denen AEM als zentrale Content-Management-Plattform mit Backend-Systemen wie SAP, Salesforce oder Azure AD integriert ist. Ein erfolgreicher Angriff kann daher vollständige Systemkompromittierung und Datenabfluss sensibler Informationen zur Folge haben.

  • · ·

    Wenn Pflegebetrieb zur Zielscheibe wird — Ransomware bei der Sozial-Holding Mönchengladbach

    VonJ. Benjamin Espagné

    Am 17. März 2025 wurde die Sozial-Holding der Stadt Mönchengladbach GmbH Opfer eines großangelegten Cyberangriffs. Die IT-Systeme der städtischen Tochtergesellschaft, die unter anderem sieben Seniorenheime betreibt und täglich Tausende Mahlzeiten ausliefert, waren betroffen: Server wurden verschlüsselt, E-Mail- und Telefoninfrastruktur war zeitweise nicht nutzbar. Die Täter forderten laut Berichten ein Lösegeld von rund 100.000 Euro. Die Sozial-Holding meldete den Vorfall bei Polizei und Datenschutzbehörden und arbeitete mit externen IT-Forensikern zusammen; nach etwa zehn Tagen war das IT-Netz wieder aufgebaut. 

    Unabhängige Medienberichte und Fachportale (dpa, WDR, CSO Online, Heise) bestätigten, dass sensible Daten von Bewohnerinnen und Bewohnern sowie Mitarbeitenden betroffen sein könnten (Personenstammdaten, Gesundheits- und Pflegedaten, Personalakten, Zugangsdaten). Die Betreiberin erklärte, die Versorgung der Bewohner sei jederzeit sichergestellt geblieben; ein Lösegeld wurde offenbar nicht bezahlt.

    Was bislang offen bleibt: Die Ermittlungen und die polizeilichen Verfahren verhinderten zunächst die Veröffentlichung technischer Details zur Angriffs-Kette und zum genauen Einstiegspunkt der Angreifer. Medienberichte sprechen von einer möglichen Beteiligung ausländischer Tätergruppen; eine gerichtliche oder behördliche Attribution war zum Zeitpunkt der Berichterstattung nicht abschließend bestätigt.

  • Komprimierte Katastrophe – WinRAR-Schwachstelle als Einfallstor

    VonJ. Benjamin Espagné

    WinRAR ist eines der bekanntesten Windows-Programme zum Komprimieren und Entpacken von Dateien. Doch im Sommer 2023 wurde eine gravierende Sicherheitslücke entdeckt: CVE-2023-38831 ermöglichte es Angreifern, beliebigen Code auf den Systemen der Opfer auszuführen.
    Obwohl die Schwachstelle kurz darauf gepatcht wurde, sind viele Systeme weltweit noch immer ungepatcht – und damit leichte Beute. Staatlich unterstützte Hackergruppen nutzen die Lücke gezielt aus, indem sie manipulierte Archive verbreiten. Diese wirken auf den ersten Blick harmlos, enthalten aber versteckte Schadsoftware, die beim Entpacken automatisch aktiv wird. Erste Angriffswellen richteten sich gegen Händler; mittlerweile sind auch Institutionen in der Ukraine und sogar Infrastrukturen in Papua-Neuguinea betroffen.

  • ·

    Doppeltes Ungemach: Henry Schein gleich zweimal von Ransomware-Angriffen betroffen

    VonJuliane Heinen

    Henry Schein, ein prominenter amerikanischer Gesundheitsriese, der in den Fortune 500 gelistet ist, ist ein wichtiger Anbieter von Produkten und Dienstleistungen in 32 Ländern in Nordamerika und Europa.

    Die Horrorgeschichte für das Unternehmen begann am 15. Oktober, als es zum ersten Mal bekannt gab, dass es als Reaktion auf die anhaltende Cyberattacke einige seiner Systeme vom Netz nahm. Das Unternehmen arbeitete teilweise mit alternativen Kommunikationsmitteln weiter. Doch die Entgegennahme tausender Bestellungen per Telefon und Messenger verlangsamte den Betrieb erheblich.

    Die dreiwöchige Untersuchung des Unternehmens ergab, dass sich die Angreifer Zugang zu sensiblen Daten wie Lieferanteninformationen, Zahlungskartennummern und Bankkontodaten verschafft hatten. Etwa zwei Wochen, nachdem Henry Schein den Angriff bekannt gegeben hatte, bekannte sich die Ransomware-Gruppe BlackCat zu dem Angriff und nahm das Unternehmen in ihre Datenleck-Site auf.

    Henry Schein war in der Lage, die Ursache der Störung zu identifizieren und versuchte, Systeme und Daten selbst wiederherzustellen. Leider griff die BlackCat-Gruppe ebenfalls ein und verschlüsselte die Daten erneut, so dass die Bemühungen des Unternehmens vergeblich waren.

    Es bleibt unklar, ob die Angreifer in der Zwischenzeit im System verblieben sind oder ob es sich um einen zweiten Einbruch handelt. Wichtig ist jedoch, dass das Unternehmen nicht dafür gesorgt hat, dass die Angreifer ferngehalten werden. Es ist sogar gut, dass sie sich so leicht erkennen ließen. In einem anderen Fall könnte eine solche Nachlässigkeit dazu führen, dass Hacker praktisch für immer in interne Systeme eindringen und einen noch größeren Schaden anrichten.

  • Cyberangriff auf Rheinische Post

    VonJuliane Heinen

    Ein massiver Hackerangriff hat die Zeitungen in NRW getroffen. Betroffen waren die Rheinische Post, der General-Anzeiger in Bonn, die Aachener Nachrichten, die Saarbrücker Zeitung und der Trierische Volksfreund – die Online- und Printausgaben der Mediengruppe Rheinische Post. Der Angriff fand am Abend des 16. Juni 2023 statt.

    Die Verlage mussten jedoch fast eine Woche lang in einem eingeschränkten Modus arbeiten und nur Notausgaben in reduziertem Umfang veröffentlichen. Das Unternehmen stellte die beschädigten Ressourcen schrittweise wieder her, um die Verbreitung möglicher Schadsoftware auf dem internen System zu verhindern. Das Unternehmen erklärte, dass die Daten der Nutzer und Kunden “sicher” seien.

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