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

    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

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

    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
  • Zwei neue Windows-Zero-Days erschüttern das Vertrauen in Microsofts Update-Kultur

    Am 15. Oktober 2025 veröffentlichte Microsoft Patches für 183 Sicherheitslücken — darunter zwei aktiv ausgenutzte Zero-Days, die grundlegende Fragen über den Zustand von Windows-Altcode aufwerfen.

    Die beiden Zero-Days

    CVE-2025-24990: Ein Treiber aus dem Jahr 2000

    Die erste Schwachstelle betrifft den Agere Modem Driver — eine Komponente, die auf jeder Windows-Version seit Windows 2000 installiert ist. Der Treiber ist auch auf Systemen vorhanden, die keine Modem-Hardware besitzen. Er wurde nie entfernt, weil er als inaktiv galt.

    Die Schwachstelle ermöglicht eine Privilegienerweiterung bis zu Systemrechten. Ein Angreifer, der bereits Code auf einem System ausführen kann (etwa nach einem erfolgreichen Phishing-Angriff), kann über den verwundbaren Treiber vollständige Kontrolle über das System erlangen.

    Microsoft kündigte an, den Treiber in zukünftigen Windows-Versionen vollständig zu entfernen — ein seltenes Eingeständnis, dass über zwei Jahrzehnte alte Komponenten ein Sicherheitsrisiko darstellen, das nicht durch Patches allein gelöst werden kann.

    CVE-2025-59230: Remote Access Connection Manager

    Die zweite Schwachstelle betrifft den Remote Access Connection Manager (RasMan) — einen Windows-Dienst, der VPN- und Einwahlverbindungen verwaltet. Auch hier ermöglicht die Lücke eine Privilegienerweiterung. RasMan läuft auf vielen Systemen als Dienst, auch wenn keine VPN-Funktionalität aktiv genutzt wird.

    Das eigentliche Problem: Legacy-Code als Angriffsfläche

    Beide Zero-Days illustrieren ein systemisches Problem: Windows trägt Altlasten aus über 25 Jahren Entwicklungsgeschichte. Treiber, Dienste und Subsysteme, die für Technologien aus den frühen 2000er Jahren entwickelt wurden, laufen auf modernen Systemen weiter — oft unbemerkt, ungepflegt und mit Privilegien, die sie längst nicht mehr haben sollten.

    Für Angreifer sind solche Legacy-Komponenten attraktiv:

    • Geringe Aufmerksamkeit: Veraltete Treiber werden selten im Security-Review berücksichtigt
    • Hohe Privilegien: Kernel-Mode-Treiber operieren mit maximalen Systemrechten
    • Universelle Präsenz: Wenn ein Treiber auf jeder Windows-Installation seit 2000 vorhanden ist, ist die Angriffsfläche global

    Das SANS Institute warnt seit Jahren, dass Privilege Escalation über Legacy-Treiber ein zunehmend genutzter Angriffsvektor ist. Die Technik ist unter der MITRE ATT&CK-ID T1068 (Exploitation for Privilege Escalation) dokumentiert.

    Was der Patch Tuesday enthielt

    Die 183 gepatchten Schwachstellen im Oktober-Update umfassten neben den beiden Zero-Days auch kritische Lücken in:

    • Microsoft Exchange Server
    • Windows Hyper-V
    • Microsoft Office
    • .NET Framework

    Die schiere Menge an Patches pro Monat — Microsoft hat 2025 durchschnittlich über 100 Schwachstellen pro Patch Tuesday behoben — verdeutlicht die Herausforderung für IT-Teams: Jeder Patch muss bewertet, getestet und deployed werden. Ohne automatisiertes Patch-Management und Priorisierung nach CISA-KEV und CVSS ist das nicht leistbar.

    Handlungsempfehlungen

    • Sofort patchen: Die beiden Zero-Days werden aktiv ausgenutzt. Priorisieren Sie CVE-2025-24990 und CVE-2025-59230 vor allen anderen Oktober-Patches
    • Legacy-Treiber auditieren: Identifizieren Sie veraltete Treiber und Dienste auf Ihren Systemen. Tools wie DriverView oder Autoruns von Sysinternals helfen bei der Bestandsaufnahme
    • Attack Surface Reduction (ASR) Rules: Microsoft Defender ASR-Regeln können die Ausnutzung verwundbarer Treiber erschweren
    • Privilege Escalation im SIEM überwachen: Alerts auf ungewöhnliche Prozesshierarchien einrichten — wenn ein Standardprozess plötzlich mit SYSTEM-Rechten läuft, ist das ein Alarm
    • Patch-Management automatisieren: Bei 100+ Patches pro Monat ist manuelles Patch-Management nicht skalierbar
  • Cybercrime auf Industrieniveau – Europol et al. zerschlagen kriminellen Dienstleister

    Europol, Eurojust und das FBI haben im Oktober 2025 ein weitreichendes Cybercrime-as-a-Service (CaaS)-Netzwerk zerschlagen. Sieben Personen wurden festgenommen, Server in Deutschland, den Niederlanden und der Tschechischen Republik beschlagnahmt. Das Netzwerk stellte anderen Kriminellen technische Infrastruktur, Schadsoftware, Hosting-Services und Zahlungssysteme zur Verfügung — ein vollständiges Ökosystem für Cyberkriminalität auf industriellem Niveau.

    Cybercrime als Dienstleistung: Das Geschäftsmodell

    Das zerschlagene Netzwerk operierte nach einem Modell, das in der Cybercrime-Szene zunehmend Standard ist: Arbeitsteilung und Spezialisierung. Statt alle Schritte eines Angriffs selbst durchzuführen, nutzen Cyberkriminelle spezialisierte Dienstleister:

    • Initial Access Broker verkaufen gestohlene Zugangsdaten und kompromittierte Systeme
    • Bulletproof Hosting Provider betreiben Server, die Takedown-Anfragen ignorieren
    • Malware-Entwickler erstellen und aktualisieren Schadsoftware als SaaS-Produkt
    • Money Mules und Krypto-Mixer waschen die Erlöse

    Laut Europol war das zerschlagene Netzwerk ein zentraler Bestandteil mehrerer größerer Ransomware-Kampagnen und diente als technischer Backbone für Betrugs- und Erpressungsoperationen. Die Ermittlungen deckten auf, dass Angriffe auf Banken, Unternehmen und öffentliche Einrichtungen europaweit koordiniert wurden.

    Die Industrialisierung der Cyberkriminalität

    Der Fall reiht sich ein in eine Serie internationaler Takedowns: Emotet (2021), Hive Ransomware (2023), LockBit (2024, Operation Cronos) und Qakbot (2023). Jede Zerschlagung zeigt dasselbe Muster: Professionelle Organisationsstrukturen, arbeitsteilige Prozesse und globale Infrastruktur.

    Der Europol Internet Organised Crime Threat Assessment (IOCTA) 2024 bestätigt den Trend: CaaS-Plattformen sind der primäre Wachstumstreiber für Cyberkriminalität. Sie ermöglichen es technisch wenig versierten Akteuren, ausgefeilte Angriffe durchzuführen — die Eintrittsbarriere sinkt, das Angriffsvolumen steigt.

    Für Unternehmen bedeutet das eine unbequeme Wahrheit: Die Gegenseite professionalisiert sich schneller als viele Verteidigungsarchitekturen. Wer seine eigene Sicherheit nicht ebenfalls industrialisiert — mit automatisierter Erkennung, 24/7-Monitoring und dokumentierten Prozessen — spielt gegen Gegner, die nach Wirtschaftlichkeitsprinzipien operieren.

    Was Takedowns bewirken — und was nicht

    Takedowns wie dieser sind wichtig: Sie unterbrechen kriminelle Infrastruktur, schaffen Ermittlungserkenntnisse und demonstrieren die Handlungsfähigkeit der Strafverfolgung. Aber sie lösen das Problem nicht grundsätzlich. Innerhalb von Wochen oder Monaten entstehen neue Plattformen, die die Lücke füllen.

    Die Konsequenz für die Verteidigung: Nicht auf die Zerschlagung einzelner Netzwerke hoffen, sondern die eigene Resilienz aufbauen.

    Handlungsempfehlungen

    • Threat Intelligence nutzen: IOCs aus Europol-Berichten und CISA-Advisories in die eigene Erkennung einbinden
    • SIEM mit aktuellen Detektionsregeln: Die Angriffsmuster der zerschlagenen CaaS-Plattformen sind bekannt — Detektionsregeln für die typischen TTPs (Phishing, Credential Theft, Lateral Movement, Ransomware Deployment) sollten aktuell sein
    • Incident-Response-Bereitschaft: Wenn CaaS-Kunden nach einem Takedown unter Druck geraten, können hastig durchgeführte Angriffe zunehmen. Die Wochen nach einem großen Takedown sind oft besonders aktiv
    • Lieferkettensicherheit: Prüfen, ob eigene Dienstleister oder Zulieferer von dem zerschlagenen Netzwerk betroffen waren
  • Shellshock-Angriffe sind wieder auf dem Vormarsch – was Sie jetzt wissen müssen

    Die Shellshock-Schwachstelle (CVE-2014-6271) wurde 2014 in der Unix-Shell Bash entdeckt und galt damals als eine der gefährlichsten Sicherheitslücken überhaupt. Über zehn Jahre später zeigen aktuelle Analysen: Shellshock-Angriffe nehmen wieder zu — und treffen Organisationen, die alte Systemkomponenten nicht aus ihrem Bestand entfernt haben.

    Was Shellshock ermöglicht

    Shellshock erlaubt Angreifern, beliebigen Code über manipulierte Umgebungsvariablen einzuschleusen, wenn Bash-Skripte in CGI-Anwendungen, SSH-ForceCommand-Konfigurationen oder DHCP-Client-Hooks verwendet werden. Ein einzelner präparierter HTTP-Request an einen verwundbaren Webserver genügt, um Befehle mit den Rechten des Webservers auszuführen.

    Die Schwachstelle betrifft alle Bash-Versionen bis 4.3. Patches wurden 2014 veröffentlicht. Dass die Schwachstelle ein Jahrzehnt später noch aktiv ausgenutzt wird, liegt an einem systematischen Problem: Legacy-Systeme, die niemand patcht, weil niemand weiß, dass sie noch laufen.

    Warum Shellshock 2025 noch relevant ist

    Laut einer Analyse von Barracuda aus dem Jahr 2024 gehört Shellshock weiterhin zu den am häufigsten gescannten und ausgenutzten Schwachstellen im Web. Die Gründe:

    • Embedded Systems und IoT: Router, NAS-Systeme, Netzwerk-Appliances und industrielle Steuerungen laufen oft mit veralteten Bash-Versionen — und werden selten oder nie gepatcht
    • Legacy-Webanwendungen: CGI-basierte Webseiten, die seit Jahren unverändert laufen, verwenden Bash zur Verarbeitung von Requests. Diese Anwendungen sind oft vergessen, aber weiterhin erreichbar
    • Automatisierte Exploit-Kits: Shellshock ist in praktisch jedem automatisierten Scanning-Tool enthalten. Die Exploitation ist trivial — ein einziger HTTP-Header reicht

    Die aktuelle Angriffswelle richtet sich laut Branchenberichten verstärkt gegen Banken und Finanzdienstleister — Branchen, die erfahrungsgemäß komplexe IT-Landschaften mit zahlreichen Legacy-Komponenten betreiben.

    Shellshock in der Lieferkette

    Ein unterschätzter Aspekt: Shellshock betrifft nicht nur eigene Systeme, sondern auch Produkte und Appliances von Drittanbietern. Netzwerk-Appliances, Firewalls, Load Balancer und IoT-Geräte können verwundbare Bash-Versionen enthalten, ohne dass der Betreiber davon weiß. Die Software Bill of Materials (SBOM) dieser Geräte — sofern überhaupt verfügbar — wird selten auf Legacy-Schwachstellen wie Shellshock geprüft.

    Erkennung und Prüfung

    Die Prüfung auf Shellshock-Verwundbarkeit ist einfach:

    env x='() { :;}; echo vulnerable' bash -c "echo test"

    Gibt das System „vulnerable” aus, ist Bash verwundbar. Für Netzwerk-Scans können Tools wie Nmap mit dem Shellshock-Skript oder spezialisierte Vulnerability-Scanner eingesetzt werden.

    Handlungsempfehlungen

    • Legacy-Inventar erstellen: Identifizieren Sie alle Systeme mit Bash — einschließlich Appliances, Embedded Systems und vergessener Webserver
    • Bash patchen oder ersetzen: Wo möglich, auf aktuelle Bash-Versionen aktualisieren. Wo nicht möglich, CGI-Anwendungen deaktivieren oder durch moderne Alternativen ersetzen
    • Netzwerksegmentierung: Legacy-Systeme, die nicht gepatcht werden können, in isolierte Netzwerksegmente verschieben
    • SIEM-Monitoring: HTTP-Logs auf typische Shellshock-Exploit-Muster überwachen (manipulierte User-Agent-Header, Cookie-Header mit Bash-Funktionsdefinitionen)
    • Lieferanten befragen: Appliance-Hersteller nach dem Bash-Versionsstand ihrer Produkte fragen — insbesondere bei Geräten, die vor 2015 ausgeliefert wurden
  • Kritische SAP-Lücke (CVE-2025-42957) aktiv ausgenutzt – wie sollten Sie reagieren?

    SecurityBridge Threat Research Labs entdeckte am 27. Juni 2025 eine kritische Code-Injection-Schwachstelle in SAP S/4HANA. CVE-2025-42957 erhielt einen CVSS-Score von 9,9 — nahezu die Höchstwertung. SAP veröffentlichte am 11. August 2025 einen Patch (Security Note 3627998). Die Ausnutzung der Schwachstelle wurde bereits bestätigt.

    Technische Details: Code Injection über RFC

    Betroffen sind On-Premise und Private Cloud Installationen von S/4HANA (S4CORE-Versionen 102–108). Ein Angreifer mit einem niedrig privilegierten Benutzerkonto kann beliebigen ABAP-Code per RFC (Remote Function Call) einschleusen. Damit umgeht er alle Autorisierungskontrollen und kann eine tarnfähige Hintertür installieren.

    Die Konsequenzen einer erfolgreichen Ausnutzung:

    • Vollständige Systemkompromittierung: Erstellung von Superuser-Konten (SAP_ALL)
    • Datendiebstahl: Zugriff auf Finanz-, HR-, Logistik- und Kundendaten
    • Passwort-Hash-Extraktion: Grundlage für weitere Angriffe
    • Geschäftsprozess-Manipulation: Änderung von Bestellungen, Rechnungen oder Zahlungsströmen
    • Ransomware-Deployment: Über die erlangte Kontrolle

    Warum SAP-Systeme besonders kritisch sind

    SAP S/4HANA ist das operative Rückgrat vieler Großunternehmen und Mittelständler. Finanzwesen, Einkauf, Produktion, Lagerhaltung und Personalwesen laufen über eine zentrale Plattform. Ein kompromittiertes SAP-System betrifft daher nicht eine Anwendung — es betrifft den gesamten Geschäftsbetrieb.

    Erschwerend kommt hinzu:

    • ABAP-Code ist offen lesbar: Die Programmiersprache ABAP erlaubt es Angreifern, veröffentlichte Patches zu reverse-engineeren und Exploits zu entwickeln
    • SAP-Patching ist komplex: SAP-Updates erfordern ausgiebige Tests, bevor sie in Produktionsumgebungen eingespielt werden. Viele Organisationen patchen SAP daher verzögert — teils um Wochen oder Monate
    • Legacy-Konfigurationen: Viele SAP-Installationen haben historisch gewachsene RFC-Konfigurationen, die weit mehr Funktionen exponieren als notwendig

    Erste Anzeichen aktiver Ausnutzung

    SecurityBridge hat die Ausnutzbarkeit der Schwachstelle verifiziert. Pathlock und das niederländische NCSC beobachteten bereits Anzeichen für Ausnutzungsversuche. Die offene Codebasis von ABAP erleichtert das Reverse Engineering der Patches — was bedeutet, dass Angreifer aus dem Patch selbst ableiten können, wo die Schwachstelle liegt.

    Sofortmaßnahmen

    1. Patch einspielen

    Security Note 3627998 auf alle S/4HANA-Installationen anwenden — On-Premise und Private Cloud. Keine Ausnahmen, keine Verzögerung.

    2. Angriffsfläche reduzieren

    • SAP UCON (Unified Connectivity) aktivieren, um nur genehmigte RFC-Funktionen zu erlauben. UCON ist die wirksamste Maßnahme, um die exponierte Angriffsfläche über RFC zu minimieren
    • Zugriff auf sensible RFCs (z.B. S_DMIS) auf das absolute Minimum beschränken

    3. Monitoring verstärken

    • Protokollanalysen auf ungewöhnliche RFC-Aufrufe, neue Admin-Nutzer und ABAP-Code-Deployments ausrichten
    • SIEM-Regeln für SAP-spezifische Anomalien konfigurieren: neue Reports, SAP_ALL-Zuweisungen, ungewöhnliche Transaktionen
    • Dateiänderungen im SAP-Transportverzeichnis über File Integrity Monitoring überwachen

    4. Resilienz schaffen

    • SAP-Umgebungen segmentieren: Produktiv-, Test- und Entwicklungssysteme strikt trennen
    • Regelmäßige, überprüfbare Backups der SAP-Datenbanken sicherstellen
    • Incident-Response-Prozesse und Eskalationspfade für SAP-spezifische Vorfälle definieren

    Einordnung

    CVE-2025-42957 ist nicht die erste kritische SAP-Schwachstelle — und wird nicht die letzte sein. SAP-Systeme sind Hochwertziele: Sie enthalten die sensibelsten Geschäftsdaten eines Unternehmens und bieten bei Kompromittierung maximalen Hebel. Die Kombination aus offener ABAP-Codebasis, komplexen Patch-Zyklen und historisch gewachsenen Berechtigungsstrukturen macht SAP-Umgebungen zu einer permanenten Herausforderung für Security-Teams.

  • Threat Analysis: ToolShell Zero-Day in Microsoft SharePoint – und wie unser SIEM schützt

    Ende Juli 2024 wurde eine Zero-Day-Schwachstelle in Microsoft SharePoint bekannt, die unter dem Namen ToolShell diskutiert wird. Angreifer nutzten gezielt die URL-Struktur /_layouts/15/ToolPane.aspx, um über Deserialisierungsfehler Schadcode einzuschleusen. Im Anschluss platzierten sie eine Webshell als .aspx-Datei im SharePoint-Verzeichnis — für dauerhaften Zugriff.

    Die Angriffskette im Detail

    Der Angriff folgt einem typischen Muster für Exploits auf Collaboration-Plattformen:

    1. Initialer Exploit über den fehlerhaften ToolPane-Endpoint — ein Deserialisierungsfehler ermöglicht Remote Code Execution
    2. Webshell-Deployment: Eine .aspx-Datei wird ins SharePoint-Webroot geschrieben (_layouts/15/ oder App_Data)
    3. Post-Exploitation: Aus dem IIS-Worker-Prozess w3wp.exe heraus werden PowerShell-Befehle ausgeführt — häufig Base64-kodiert, um Detection zu umgehen
    4. Persistenz: Zugriff auf Kryptografie-Keys ermöglicht dauerhafte Backdoors, die auch nach einem Neustart bestehen bleiben

    Patch-Status und Workarounds

    Microsoft hat Sicherheitsupdates für SharePoint 2019 und die Subscription Edition bereitgestellt. Für ältere Versionen wie SharePoint 2016 gelten gesonderte Workarounds. CISA und mehrere Security-Firmen haben Indicators of Compromise (IOCs) und TTP-Beschreibungen veröffentlicht.

    Die gute Nachricht: Auch ohne sofortigen Patch lassen sich die Aktivitäten des Angriffs über Logs und Verhaltensanalyse erkennen.

    Erkennungsmuster für SIEM-Monitoring

    ToolShell hinterlässt charakteristische Spuren, die ein SIEM mit den richtigen Regeln zuverlässig erkennt:

    • IIS-Logs: Zugriffe auf /_layouts/15/ToolPane.aspx mit verdächtigen Parametern — insbesondere POST-Requests mit ungewöhnlichen Payloads
    • File Integrity Monitoring (FIM): Neue .aspx-Dateien in SharePoint-Verzeichnissen, die nicht durch reguläre Deployments erstellt wurden
    • Prozessüberwachung: w3wp.exe startet powershell.exe oder cmd.exe — ein klarer Indikator für Post-Exploitation. Besonders verdächtig: Parameter wie -EncodedCommand oder FromBase64String
    • Netzwerk-Anomalien: Ausgehende Verbindungen des IIS-Workers zu externen IPs unmittelbar nach Dateiänderungen im Webroot

    SharePoint als Angriffsfläche

    SharePoint ist in vielen Unternehmen ein zentraler Knotenpunkt: Dokumentenmanagement, Intranet, Workflow-Automatisierung und Collaboration laufen über die Plattform. Ein kompromittierter SharePoint-Server bietet Angreifern Zugang zu internen Dokumenten, Zugangsdaten und lateraler Bewegung ins Unternehmensnetz.

    Die Kombination aus hoher Verbreitung, komplexer Konfiguration und häufig verzögertem Patching macht SharePoint zu einem wiederkehrenden Ziel. Frühere kritische Schwachstellen wie CVE-2023-29357 (Privilege Escalation) und CVE-2024-38094 (RCE) zeigen das Muster.

    Handlungsempfehlungen

    • Sofort patchen: SharePoint auf die aktuelle gepatchte Version aktualisieren — insbesondere SharePoint 2019 und Subscription Edition
    • IIS-Logs in SIEM einbinden: Zugriffe auf bekannte Exploit-Pfade überwachen und alarmieren
    • File Integrity Monitoring aktivieren: Neue Dateien in SharePoint-Verzeichnissen müssen erkannt und bewertet werden
    • Prozessbaseline erstellen: Definieren, welche Prozesse w3wp.exe normalerweise startet — alles andere ist ein Alarm
    • Compromise Assessment: Wenn SharePoint vor dem Patch aus dem Internet erreichbar war, auf Webshells und Backdoors prüfen
  • RMM-Systeme im Visier –N-able N-central Schwachstellen

    Am 15. August 2025 meldete die Shadowserver Foundation, dass über 1.000 N-able N-central Instanzen weltweit noch ungepatcht gegen die Sicherheitslücken CVE-2025-8875 und CVE-2025-8876 waren. Beide Schwachstellen wurden in den Known Exploited Vulnerabilities (KEV)-Katalog der CISA aufgenommen — eine Bestätigung, dass sie bereits aktiv ausgenutzt werden.

    Warum RMM-Systeme hochwertige Ziele sind

    N-central ist eine Remote-Monitoring-and-Management-Lösung (RMM), die vor allem von Managed Service Providern (MSPs) genutzt wird, um Kundensysteme zentral zu überwachen und zu administrieren. Ein kompromittiertes RMM-System ist für Angreifer der Jackpot: Es bietet administrative Kontrolle über hunderte oder tausende Endpunkte gleichzeitig — über alle Kunden des MSP hinweg.

    Die Angriffsfläche ist enorm: RMM-Tools haben per Design privilegierten Zugriff auf alle verwalteten Systeme. Wer das RMM kontrolliert, kann Software installieren, Konfigurationen ändern, Daten exfiltrieren und Ransomware ausrollen — auf allen verwalteten Geräten gleichzeitig. Der Kaseya-Vorfall im Juli 2021 demonstrierte dieses Szenario in der Praxis: Über eine Schwachstelle in Kaseya VSA wurden mehr als 1.500 Unternehmen weltweit mit REvil-Ransomware infiziert.

    Die Schwachstellen im Detail

    CVE-2025-8875 und CVE-2025-8876 ermöglichen Angreifern die nicht autorisierte Ausführung von Befehlen auf verwundbaren N-central-Instanzen. Laut Shadowserver sind die USA, Kanada, die Niederlande und Großbritannien besonders stark betroffen.

    N-able hat die Schwachstellen mit Version N-central 2025.3.1 behoben. Shadowserver integrierte die Erkennung beider CVEs Mitte August 2025 in seine täglichen Scans und benachrichtigt betroffene Betreiber direkt.

    Supply-Chain-Risiko durch MSPs

    Der Fall verdeutlicht ein strukturelles Problem: MSPs sind Single Points of Failure für ihre Kunden. Ein kompromittierter MSP kompromittiert potenziell alle seine Kunden — ein klassisches Supply-Chain-Risiko. Die NIS2-Richtlinie adressiert dieses Risiko explizit: Unternehmen müssen die Sicherheit ihrer IT-Dienstleister in ihr Risikomanagement einbeziehen.

    Für Unternehmen, die MSP-Dienste nutzen, stellen sich konkrete Fragen:

    • Welche RMM-Lösung nutzt mein MSP — und ist sie aktuell gepatcht?
    • Hat mein MSP einen dokumentierten Patch-Management-Prozess?
    • Wie schnell reagiert mein MSP auf CISA-KEV-Einträge?
    • Gibt es Netzwerksegmentierung zwischen den Kunden des MSP?

    Handlungsempfehlungen

    • Sofort patchen: Alle N-central-Instanzen auf Version 2025.3.1 oder höher aktualisieren
    • MSP-Kunden: Ihren Dienstleister aktiv nach dem Patch-Status fragen — nicht darauf warten, dass er sich meldet
    • RMM-Zugriffe im SIEM überwachen: Alle administrativen Aktionen über RMM-Tools protokollieren und auf Anomalien prüfen
    • Netzwerksegmentierung: RMM-Server in einem dedizierten Segment betreiben, nicht im gleichen Netz wie Produktionssysteme
    • Conditional Access: RMM-Zugriffe auf autorisierte IPs und Geräte beschränken
  • Citrix NetScaler CVE-2025-7775: Patching-Fortschritt im Fokus

    Am 26. August 2025 wurde eine kritische Zero-Day-Sicherheitslücke in Citrix NetScaler ADC und NetScaler Gateway bekannt. CVE-2025-7775 ist ein Memory Overflow, der Remote Code Execution (RCE) oder Denial of Service (DoS) ohne Authentifizierung ermöglicht. Citrix bestätigte aktive Angriffe in freier Wildbahn und empfahl sofortige Updates.

    CISA reagiert mit Notfall-Frist

    Die CISA nahm CVE-2025-7775 in ihren Known Exploited Vulnerabilities (KEV)-Katalog auf und setzte US-Bundesbehörden eine Frist bis zum 28. August 2025 — nur zwei Tage nach Bekanntwerden. Eine derart kurze Frist signalisiert: Die Bedrohung ist akut und der Exploit wird aktiv eingesetzt.

    Patching-Fortschritt: Europa patcht schneller

    Shadowserver-Scans zeigen den globalen Patching-Fortschritt in Echtzeit. Die Zahlen:

    • Ausgangslage: Rund 28.200 verwundbare NetScaler-Instanzen weltweit
    • Nach zwei Wochen: Etwa 12.400 Instanzen noch ungepatcht — ein Rückgang von 56 Prozent
    • Regionale Unterschiede: Europa patcht deutlich schneller als Nordamerika

    Dass nach zwei Wochen noch über 12.000 Instanzen verwundbar sind, ist alarmierend. NetScaler ADC und Gateway sind Per-Design aus dem Internet erreichbar — sie sind Load Balancer, VPN-Gateways und Application Delivery Controller. Jede ungepatchte Instanz ist ein offenes Tor.

    NetScaler: Wiederkehrendes Angriffsziel

    CVE-2025-7775 ist nicht die erste kritische NetScaler-Schwachstelle. Die Geschichte wiederholt sich:

    • CVE-2023-3519 (Juli 2023): RCE ohne Authentifizierung, aktiv ausgenutzt, CISA-KEV
    • CVE-2023-4966 „Citrix Bleed” (Oktober 2023): Session-Hijacking, massenhaft ausgenutzt durch LockBit und andere
    • CVE-2024-3519 (2024): Weitere RCE in NetScaler Gateway

    Das Muster ist konsistent: NetScaler-Appliances stehen am Netzwerkrand, haben hohe Privilegien und werden von Angreifern systematisch auf neue Schwachstellen gescannt. Organisationen, die NetScaler einsetzen, müssen Patching dieser Systeme als höchste Priorität behandeln — nicht als regulären Wartungszyklus.

    Warum Patching allein nicht reicht

    Der Zeitraum zwischen Bekanntwerden einer Schwachstelle und dem vollständigen Patching aller Instanzen beträgt selbst bei kritischen Zero-Days Wochen. In dieser Zeit sind ungepatchte Systeme exponiert. Zusätzliche Maßnahmen:

    • Web Application Firewall (WAF) Rules: Virtuelle Patches können die Ausnutzung blockieren, bis der offizielle Patch eingespielt ist
    • Network-Level-Einschränkungen: Management-Interfaces und unnötige Dienste von außen unzugänglich machen
    • SIEM-Monitoring: NetScaler-Logs in das zentrale Monitoring einbinden. Ungewöhnliche Anfragemuster, Zugriffe auf bekannte Exploit-Pfade und verdächtige Prozesse auf der Appliance überwachen
    • Compromise Assessment: Bei Systemen, die vor dem Patching exponiert waren, prüfen, ob bereits eine Kompromittierung stattgefunden hat. Patchen allein beseitigt keine bereits platzierten Backdoors

    Handlungsempfehlungen

    • Sofort patchen: Alle NetScaler ADC und Gateway-Instanzen auf die von Citrix empfohlene Version aktualisieren
    • Exponierte Instanzen identifizieren: Shadowserver-Benachrichtigungen prüfen oder eigene Scans durchführen
    • Post-Patch-Forensik: Systeme, die vor dem Patch aus dem Internet erreichbar waren, auf Kompromittierungsindikatoren prüfen
    • Schwachstellenmanagement-Prozess etablieren: CISA-KEV-Einträge als automatischen Trigger für Notfall-Patching definieren

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