KritischCVE-2024-40711

    Veeam Backup and Recovery: Deserialisierung nicht vertrauenswürdiger Daten (CVE-2024-40711)

    Veröffentlicht In CISA KEV seit Quellen: CVE.org, pwn.watch

    Was ist betroffen, was ist zu tun

    Ein Deserialisierungsfehler in Veeam Backup and Replication ermöglicht es einem unauthentifizierten Angreifer, Remote-Code-Ausführung (RCE) durchzuführen. Das Problem betrifft Versionen von 12.0.0.1420 bis 12.2.0.334. Es wird aktiv in Ransomware-Kampagnen seit Oktober 2024 ausgenutzt. Ein sofortiges Patchen auf die neueste Version ist dringend erforderlich, um die Sicherheit zu gewährleisten.

    Die Schwachstelle wird aktiv ausgenutzt; behandeln Sie sie vorrangig. CISA führt sie als in Ransomware-Kampagnen genutzte Schwachstelle. Aktualisieren Sie veeam_backup_\&_replication auf Version 12.2.0.334. Sofortmaßnahmen, Mitigation und Erkennungsregeln stehen im Runbook unten.

    Betroffen
    • Veeam Backup and Recovery lte 12.1.2..12.1.2

    Unklar, ob und wie Sie betroffen sind? Frage zu dieser Schwachstelle stellen

    Metriken

    9,8

    Priorität

    XIEM Effective CVSS: höchste verfügbare CVSS-Bewertung aus NVD- und Herstellerangaben.

    Quelle: NVD, CVSS v3

    9,8

    CVSS v3

    Schweregrad Kritisch auf der Skala von 0 bis 10.

    Quelle: CVE.org, pwn.watch

    90,4 %

    EPSS-Score

    Hoch – Modell schätzt ≥ 50 % Chance auf reale Ausnutzung in 30 Tagen.

    Quelle: FIRST EPSS, Perzentil 99,80

    Alle Metriken anzeigen
    Schweregrad
    Kritisch
    Priorität (0–325)

    Der Priorisierungs-Score ist eine zusammengeführte Kennzahl, die mehrere Einzelsignale zu einer einzigen, handlungsleitenden Rangfolge verdichtet: technische Schwere (CVSS), Ausnutzungswahrscheinlichkeit (EPSS), der Status als bekannt ausgenutzt (KEV) und der Kontext des betroffenen Assets. Ziel ist die Antwort auf die einzig wirklich wichtige Frage im Schwachstellenmanagement: Was zuerst?

    Im Glossar lesen
    259.89 Methodik
    Exploit-Reife

    Ein Exploit ist Code oder eine Technik, die eine konkrete Schwachstelle gezielt ausnutzt, um ein unbeabsichtigtes Verhalten zu erzwingen — etwa Code auszuführen oder Rechte auszuweiten. Er ist das Werkzeug, das aus einer theoretischen Lücke einen praktischen Angriff macht.

    Im Glossar lesen
    aktiv ausgenutzt
    XIEM Effective CVSS

    XIEM® ist das gestufte Managed-Security-Betriebsmodell von NEOSEC und eine eingetragene Marke der NEOSEC GmbH. Es erweitert klassisches SIEM — die zentrale Sammlung, Normalisierung und Korrelation sicherheitsrelevanter Ereignisse — um Endpunkt-Forensik, Netzwerk-Sichtbarkeit und Täuschungstechnik und führt diese zu drei aufeinander aufbauenden Stufen zusammen: Sentry, Orchestrate und Command.

    Im Glossar lesen
    9,8 Methodik
    CVSS v3

    CVSS ist der weltweit verbreitete, offene Standard zur Bewertung der technischen Schwere einer Schwachstelle auf einer Skala von 0 bis 10. Er beschreibt, wie leicht eine Lücke ausnutzbar ist und welchen Schaden sie anrichten kann — nicht jedoch, wie wahrscheinlich ihre tatsächliche Ausnutzung ist. CVSS und das ergänzende EPSS beantworten bewusst unterschiedliche Fragen.

    Im Glossar lesen
    9,8
    EPSS-Score

    Der EPSS-Score ist der absolute Modell-Output für eine einzelne Schwachstelle: die geschätzte Wahrscheinlichkeit einer realen Ausnutzung in den nächsten 30 Tagen, ausgedrückt als Wert zwischen 0 und 1 (bzw. 0 % bis 100 %). Ein Score von 0,42 bedeutet „das Modell schätzt eine 42-prozentige Chance auf reale Ausnutzung binnen 30 Tagen“.

    Im Glossar lesen
    90,4 %
    Hoch – Modell schätzt ≥ 50 % Chance auf reale Ausnutzung in 30 Tagen.
    EPSS-Perzentil

    Das EPSS-Perzentil ist die relative Einordnung einer Schwachstelle innerhalb aller EPSS-bewerteten CVEs, ausgedrückt als Wert zwischen 0 und 1. Ein Perzentil von 0,90 bedeutet „diese CVE hat einen höheren EPSS-Score als 90 % aller anderen bewerteten CVEs“. Anders als der EPSS-Score ist es keine Wahrscheinlichkeit — sondern eine Positionierung im Ranking.

    Im Glossar lesen
    99,80
    Kritisch – CVE liegt im obersten Fünftel aller heute bewerteten CVEs (Rang ≥ 80 %).
    KEV-Status

    Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.

    Im Glossar lesen
    Aktiv ausgenutzt
    Veröffentlicht
    In CISA KEV seit

    Der KEV-Katalog ist eine von der US-Behörde CISA gepflegte Liste von Schwachstellen, für die eine aktive Ausnutzung in der Praxis nachgewiesen ist. Er beantwortet nicht die Frage „wie schwer?“, sondern „wird es bereits angegriffen?“ — und priorisiert damit das Patchen scharf.

    Im Glossar lesen

    Behebung und Mitigation

    Warum sofort handeln?

    Priorisierung

    Die Schwachstelle ist ohne Authentifizierung über das Netzwerk mit geringer Komplexität ausnutzbar und führt zur vollständigen Kompromittierung des Backup-Servers. Die Ausnutzungswahrscheinlichkeit gilt als sehr hoch, und CISA führt eine bekannte Nutzung in Ransomware-Kampagnen. Angreifer nutzen den VBR-Server gezielt, um vor der Verschlüsselung Sicherungen zu löschen und gespeicherte Zugangsdaten zu Hypervisoren und zur Domäne abzugreifen. Damit wird ein einzelner Server zum Schlüssel für die gesamte Infrastruktur. Für jede Organisation mit Veeam 12.x ist dies Priorität 1 mit Patch innerhalb von 24 h. Bei Erreichbarkeit aus VPN- oder Benutzernetzen gilt die Lage als akuter Notfall mit sofortiger Kompromittierungsprüfung.

    1. Schritt 1 im Runbook

      Sofort-Response (0-24 h)

      • Patch einspielen: Alle Veeam Backup & Replication-Server der Version 12.x auf Build 12.2.0.334 oder neuer aktualisieren. Den aktuellsten Fix-Build und die KB-Referenz im Veeam Security Bulletin nachschlagen. Betroffen ist laut Kontext der Bereich 12.0.0.1420 bis 12.2.0.334. Den installierten Build über „Help > About“ in der Konsole oder per Dateiversion von Veeam.Backup.Service.exe verifizieren.
      • Inventarisierung: Alle VBR-Server, Konsolen-Installationen und Proxys erfassen, auch Altinstallationen in Außenstellen und bei Dienstleistern. Ungepatchte Systeme sofort als kritisch kennzeichnen.
      • Netzwerkzugriff sperren: Bis zum Patch eingehende Verbindungen zum VBR-Server ausschließlich aus dem Backup-Management-Netz zulassen. Öffentliche Forschung beschreibt die Ausnutzung über den Mount-Service auf TCP 8000. Diesen Port sowie die übrigen Veeam-Dienstports per Host-Firewall auf bekannte Proxy- und Repository-IPs beschränken. Keine Erreichbarkeit aus dem VPN-Benutzernetz zulassen.
      • Kompromittierungsprüfung: Auf ungepatchten Systemen nach neu angelegten lokalen Konten und unerwarteten Mitgliedern der Gruppen „Administratoren“ und „Remotedesktopbenutzer“ suchen. Bei einem Treffer das System isolieren und den Vorfall gemäß NIS2-Meldeprozess eskalieren (Frühwarnung innerhalb von 24 h).
      • Zugangsdaten rotieren: Bei Verdacht alle in der Veeam-Konfigurationsdatenbank hinterlegten Zugangsdaten zurücksetzen. Dazu gehören vCenter/ESXi, Hyper-V, Domänenkonten, Repository-, Cloud- und SQL-Konten.
      • VPN-Zugänge härten: Fernzugänge ohne MFA sofort absichern. Kompromittierte VPN-Konten waren ein häufig beobachteter Erstzugang, über den der VBR-Server anschließend erreicht wurde.

    2. Schritt 2 im Runbook

      Mitigation-Layer

      • Netzwerksegmentierung: Den VBR-Server in ein eigenes Management-VLAN legen. Ein Default-Deny gilt sowohl für Clients und VPN-Pools als auch für das Internet. Ausgehende Verbindungen nur zu definierten Zielen erlauben: Hypervisor, Repositories und Veeam-Update-Server.
      • IPS/NDR: Alarmieren bei Verbindungen auf TCP 8000 und weitere Veeam-Dienstports, deren Quelle nicht zu den bekannten Veeam-Komponenten gehört. Zusätzlich nach .NET-Remoting- bzw. BinaryFormatter-Payloads in Richtung des VBR-Servers suchen, sofern der Hersteller der IPS-Lösung Signaturen für CVE-2024-40711 bereitstellt.
      • Identitäts- und Rechteverwaltung: Den VBR-Server gemäß Veeam-Best-Practice nicht in die Produktionsdomäne einbinden, sondern eine separate Management-Domäne oder Workgroup nutzen. Dienstkonten mit minimalen Rechten betreiben und für die Konsolenanmeldung MFA aktivieren.
      • Backup-Resilienz: Unveränderliche Sicherungen nutzen, etwa ein Hardened Linux Repository, S3 Object Lock oder eine Offline-Kopie nach der 3-2-1-1-0-Regel. So sind Wiederherstellungsdaten auch bei kompromittiertem VBR-Server geschützt. Die Immutability-Zeiträume prüfen.
      • Endpunkthärtung: Mit EDR bzw. ASR-Regeln verhindern, dass Veeam-Dienstprozesse cmd.exe, powershell.exe, net.exe oder net1.exe starten. Zuvor im Audit-Modus testen.

    3. Schritt 3 im Runbook

      Detection-Regeln

      • Prozessabstammung (Sysmon EID 1 / EDR): Ein Veeam-Dienst als Elternprozess startet eine Shell oder ein Administrationswerkzeug. Sigma-Form: ParentImage|endswith: '\Veeam.Backup.MountService.exe' AND Image|endswith: ['\cmd.exe','\powershell.exe','\net.exe','\net1.exe'].
      • Kontoanlage (Windows Security Log): Event ID 4720 (Benutzer angelegt), gefolgt von 4732 (Aufnahme in eine lokale Gruppe wie Administratoren oder Remotedesktopbenutzer) auf dem VBR-Host. KQL: SecurityEvent | where Computer has "vbr" and EventID in (4720,4732).
      • Laterale Bewegung: Event ID 4624 mit LogonType 10 (RDP) oder 3 durch neu angelegte Konten auf dem VBR-Server. Ebenfalls verdächtig sind Anmeldungen kurz nach einer VPN-Sitzung ohne MFA.
      • Netzwerktelemetrie (Zeek/Suricata): conn.log auf eingehende Verbindungen zu id.resp_p == 8000 am VBR-Server auswerten, deren Quelle nicht zu Proxys oder Repositories gehört. SPL: index=zeek dest_ip=<VBR> dest_port=8000 NOT src_ip IN (<veeam_components>).
      • Credential-Abfluss: Zugriffe auf die Veeam-Konfigurationsdatenbank (SQL/PostgreSQL) durch nicht-Veeam-Prozesse beobachten. Auffällig sind auch Ausführungen von sqlcmd.exe oder PowerShell-Skripten mit Veeam-Credential-Dump-Mustern.

    Erkennungsregeln

    Für diese Schwachstelle liegt noch keine NEOSEC-Erkennungsregel vor.

    Einordnung nach NIS2 und CRA

    Regelbasierte Einordnung aus Ausnutzungsstatus und Schweregrad. Sie ersetzt keine Prüfung im Einzelfall.

    NIS2

    NIS2 ist die EU-Richtlinie (EU) 2022/2555 zur Erhöhung des Cybersicherheitsniveaus in der Union. Sie weitet Pflichten gegenüber der ersten NIS-Richtlinie deutlich aus: mehr Sektoren, verbindliches Risikomanagement, gestufte Meldepflichten und persönliche Verantwortung der Geschäftsleitung.

    Im Glossar lesen
    Aktiv ausgenutzt: Behandeln Sie die Schwachstelle im Schwachstellenmanagement nach Art. 21 Abs. 2 lit. e NIS2 vorrangig. Wird sie in Ihrer Umgebung ausgenutzt, prüfen Sie die Meldepflicht nach Art. 23 (Frühwarnung binnen 24 Stunden).
    CRA

    Der CRA ist die EU-Verordnung (EU) 2024/2847 mit horizontalen Cybersicherheitsanforderungen an „Produkte mit digitalen Elementen“ — von Industriesteuerungen über Software bis zu vernetzten Verbrauchergeräten. Erstmals müssen Hersteller Sicherheit über den gesamten Produktlebenszyklus gewährleisten, Schwachstellen behandeln und Sicherheitsupdates bereitstellen.

    Im Glossar lesen
    Seit dem 11.09.2026 müssen Hersteller betroffener Produkte mit digitalen Elementen aktiv ausgenutzte Schwachstellen nach Art. 14 CRA melden, mit Frühwarnung binnen 24 Stunden über die zentrale Meldeplattform der ENISA.
    ISO/IEC 27001

    ISO/IEC 27001 ist der international führende Standard für ein Informationssicherheits-Managementsystem (ISMS). Er beschreibt einen risikobasierten, prozessorientierten Rahmen, um Informationssicherheit systematisch zu planen, umzusetzen, zu überprüfen und zu verbessern.

    Im Glossar lesen
    Maßnahme A.8.8, Management technischer Schwachstellen: Relevanz für Ihre Systeme bewerten, Behebung einplanen und nachweisen.

    Beschreibung

    Eine Schwachstelle bei der Deserialisierung von nicht vertrauenswürdigen Daten mit einem bösartigen Payload kann eine unbefugte Ferncodeausführung (RCE) ermöglichen.

    Originalquelle nur englisch verfügbar, maschinell ins Deutsche übersetzt.

    Quelle: cvelistv5, pwn.watch, NVD (NIST), CISA KEV Catalog, CVE.org (MITRE)

    Betroffene Produkte

    Betroffen sind die folgenden Versionen. Ältere Stände derselben Reihe sind ebenfalls verwundbar, sofern nicht anders angegeben.

    Betroffene Produkte
    Betroffene VersionenBehoben in
    VeeamBackup and Recovery
    • ≤ 12.1.2
    • —
    veeamveeam_backup_\&_replication
    • 12.0.0.1420 – < 12.2.0.334
    • 12.2.0.334

    Hersteller und Produkte

    Öffentliche Exploit-Referenzen

    Öffentlich gemeldete Proof-of-Concepts, Exploit-Module und Detection-Templates zu dieser Schwachstelle. NEOSEC verlinkt ausschließlich auf die Originalquellen und stellt keinen Exploit-Code bereit.

    Öffentliche Exploit-Referenzen
    CISA KEV CatalogCISA Known Exploited Vulnerability (öffnet in neuem Tab)cisa.govaktiv ausgenutzt
    Referenz mit Exploit-Kennzeichnunglabs.watchtowr.com (öffnet in neuem Tab)PoC (öffentlich gemeldet)gemeldet, nicht verifiziert—

    Quellen & Referenzen

    • veeam.comVeeam advisory: CVE-2024-40711Herstellerhinweis, pwn-watch
    • labs.watchtowr.comveeam-backup-response-rce-with-auth-but-mostly-without-auth-cve…Exploit, Hinweis Dritter
    • cisa.govknown-exploited-vulnerabilities-catalog?field_cve=CVE-2024-40711government-resource, US-Behörde
    • pwn.watchpwn.watch: Veeam Backup and Replication Deserializationpwn-watch
    • NVD (NIST)NVD: CVE-2024-40711pwn-watch
    • cisa.govCISA Known Exploited Vulnerabilities Catalogpwn-watch
    Badge einbetten

    Zeigen Sie Schweregrad und KEV-Status dieser Schwachstelle auf Ihrer Seite – mit Link hierher. Das Bild wird stündlich aktualisiert.

    Badge-Vorschau für CVE-2024-40711
    <a href="https://intel.neosec.eu/cve/CVE-2024-40711"><img src="https://intel.neosec.eu/badge/cve/CVE-2024-40711.svg" alt="CVE-2024-40711 – NEOSEC Intel" height="20"></a>