Ein scheinbar harmloser Support-Chat wurde für DigiCert zu einem Angriff auf eine besonders sensible Vertrauensebene: Code Signing. Laut der bei Mozilla dokumentierten Incident-Beschreibung kontaktierte ein Angreifer am 2. April 2026 den DigiCert-Support über einen Kunden-Chat-Kanal und übermittelte eine ZIP-Datei, die wie ein Screenshot wirken sollte, aber eine schädliche .scr-Datei enthielt ^[12]. Über kompromittierte Supportsysteme konnten anschließend Initialisierungscodes für eine begrenzte Zahl von Code-Signing-Zertifikaten erlangt werden; einige davon wurden zum Signieren von Malware genutzt ^[1].

Was genau passiert ist

Der Angriff begann als gezieltes Social Engineering gegen DigiCerts Support. Help Net Security beschreibt den Kern ähnlich wie die Incident-Dokumentation: Eine als Kundenscreenshot getarnte ZIP-Datei enthielt eine Windows-Screensaver-Datei mit Schadfunktion ^[2].

SecurityWeek berichtet, dass die Malware zwei Endpunkte infizierte; ein betroffener Endpunkt wurde demnach am 3. April erkannt, ein weiterer am 14. April ^[10]. Von einem kompromittierten System aus sollen die Angreifer auf ein internes Supportportal gewechselt sein ^[10]. Dort konnten authentifizierte Support-Analysten über eine begrenzte Funktion in Kundenkonten wechseln; diese Funktion ermöglichte laut SecurityWeek Zugriff auf bestimmte Funktionen, darunter Initialisierungscodes für ausstehende Zertifikate ^[10]. BleepingComputer beschreibt den Umfang ebenfalls als begrenzt, nennt aber konkret Initialisierungscodes für bereits genehmigte, noch nicht ausgelieferte EV-Code-Signing-Zertifikate ^[5].

Warum EV-Code-Signing-Zertifikate ein lohnendes Ziel sind

Code-Signing-Zertifikate sind Teil der Vertrauenskette für Softwareverteilung: Sie helfen dabei, Herkunft und Integrität von Software zu bewerten. DigiCert spielt als Zertifizierungsstelle eine zentrale Rolle für Internetkommunikation und Softwareverteilung; seine Code-Signing-Zertifikate werden von Softwareentwicklern genutzt ^[11].

Der Sicherheitsbruch lag deshalb nicht nur im Zugriff auf Supportsysteme, sondern im Missbrauch dieser Vertrauenswirkung. ThreatNoir berichtet, dass einige der erlangten Code-Signing-Zertifikate zum Signieren von Malware verwendet wurden ^[1]. CyberInsider beschreibt ebenfalls einen Vorfall, bei dem kompromittierte interne Supportsysteme und Zertifikatsausstellungsdaten zum Erhalt gültiger EV-Code-Signing-Zertifikate missbraucht wurden; einige Zertifikate seien später zum Signieren von Malware genutzt worden ^[11].

Das ist gefährlich, weil signierte Malware auf den ersten Blick legitimer wirken kann. Vectra beschreibt dieses Muster allgemein: Angreifer können EV-Zertifikate nutzen, um schädliche Dateien zu signieren und das erhöhte Vertrauen in EV-signierte Anwendungen auszunutzen; Organisationen, die nur auf signaturbasiertes Vertrauen setzen, bleiben dadurch verwundbar ^[15].

Was nicht belegt ist

Wichtig ist die Abgrenzung: Die vorliegenden Quellen beschreiben kompromittierte Support-Endpunkte, interne Supportfunktionen und den Zugriff auf Initialisierungscodes ^{[1][5][10][12]}. Sie belegen keine Kompromittierung von DigiCert-Root-Schlüsseln oder CA-Schlüsseln.

Das macht den Vorfall nicht harmlos. Es bedeutet aber, dass der bekannte Angriff nach den verfügbaren Berichten nicht als vollständige Übernahme der Zertifizierungsstelle beschrieben wird, sondern als Missbrauch eines Support- und Ausstellungsprozesses rund um Code-Signing-Zertifikate ^[1][5][10].

Wie groß war der Schaden?

Die öffentliche Zahlenlage ist nicht vollständig einheitlich, weil Quellen unterschiedliche Kategorien nennen:

• ThreatNoir spricht von einer begrenzten Zahl von Code-Signing-Zertifikaten, von denen einige zum Signieren von Malware verwendet wurden ^[1].
• Risky Business berichtet von 27 gestohlenen Code-Signing-Zertifikaten, die später zum Signieren von Malware genutzt worden seien ^[8].
• ThreatLocker nennt 60 insgesamt widerrufene Code-Signing-Zertifikate ^[3].

Für die Bewertung ist deshalb entscheidend, ob eine Quelle über erlangte, missbrauchte oder widerrufene Zertifikate spricht. Der Vorfall war nach den Berichten begrenzt, aber sicherheitsrelevant, weil bereits wenige gültig wirkende Code-Signing-Zertifikate für Malware-Kampagnen ausreichen können, um Vertrauen auszunutzen ^[1][15].

Eindämmung: Widerruf und Stornierung offener Aufträge

DigiCert widerrief die identifizierten Zertifikate laut BleepingComputer innerhalb von 24 Stunden nach Entdeckung und setzte das Widerrufsdatum auf das Ausstellungsdatum zurück ^[5]. Pending Orders im betroffenen Zeitraum wurden demnach vorsorglich storniert ^[5]. ThreatNoir berichtet ebenfalls, dass betroffene Zertifikate innerhalb von 24 Stunden widerrufen und ausstehende Bestellungen im betroffenen Zeitfenster annulliert wurden ^[1].

Der Widerruf begrenzt weiteren Missbrauch, beendet die operative Arbeit für Verteidiger aber nicht. Sicherheitsteams müssen signierte Dateien weiterhin anhand von Zertifikatsdaten, Hashes, Verhalten und Threat-Intelligence-Kontext bewerten, weil EV-Signaturen von Angreifern gezielt als Vertrauenssignal missbraucht werden können ^[15].

Der Defender-Nebeneffekt: echte Warnlage, falsche Alarme

Rund um den Vorfall kam es zusätzlich zu Verwirrung durch Microsoft Defender. BleepingComputer berichtete, Microsoft Defender habe DigiCert-Zertifikate fälschlich als Trojan:Win32/Cerdigent.A!dha erkannt ^[5]. Daily.dev fasste zusammen, Defender habe legitime DigiCert-Root-Zertifikate nach einem Signaturupdate am 30. April fälschlich markiert; Microsoft habe später mit Security-Intelligence-Update 1.449.430.0 nachgebessert und entfernte Zertifikate wiederhergestellt ^[7].

Für Unternehmen war das ein praktisches Incident-Response-Problem: Teams mussten gleichzeitig echten Zertifikatsmissbrauch, mögliche Warnungen gegen signierte Malware und Fehlalarme gegen legitime Zertifikate auseinanderhalten ^[5][7].

Was Sicherheitsteams daraus lernen sollten

Die wichtigste Lehre ist nicht, dass Code Signing wertlos wäre. Die Lehre ist, dass Code Signing nur ein Vertrauenssignal unter mehreren sein darf.

Praktisch heißt das:

• Signaturen prüfen, nicht blind akzeptieren. Eine gültige oder EV-basierte Signatur sollte nicht automatisch bedeuten, dass eine Datei vertrauenswürdig ist; Angreifer können EV-Zertifikate gezielt zum Signieren schädlicher Dateien einsetzen ^[15].
• Zertifikatsdetails einbeziehen. Aussteller, Seriennummer, Zertifikatskette, Zeitstempel und Widerrufsstatus sind entscheidend, wenn ein signiertes Binary verdächtig ist; im DigiCert-Fall waren Widerruf und Rückdatierung des Widerrufsdatums zentrale Eindämmungsmaßnahmen ^[5].
• Dateiverhalten stärker gewichten. Hashes, Prozessverhalten, Netzwerkverbindungen, Persistenzmechanismen und Sandbox-Ergebnisse sollten zusammen mit der Signatur bewertet werden, weil signierte Malware bewusst Vertrauen ausnutzt ^[15].
• Support- und Admin-Portale als Hochrisiko-Zonen behandeln. Der Vorfall zeigt, dass auch begrenzte Supportfunktionen sicherheitskritisch werden können, wenn sie Zugriff auf Kundenkonten oder Initialisierungscodes für Zertifikate ermöglichen ^[10].
• Fehlalarme kontrolliert bearbeiten. Die Defender-Berichte zeigen, dass Zertifikatswarnungen nicht automatisch eine echte Infektion bedeuten; legitime DigiCert-Root-Zertifikate wurden laut Daily.dev fälschlich erkannt und später durch ein Microsoft-Update wiederhergestellt ^[7].

Fazit

Der DigiCert-Vorfall war sicherheitsrelevant, weil Angreifer die Vertrauenswirkung von EV-Code-Signing-Zertifikaten gegen Verteidiger ausnutzen konnten. Die verfügbaren Berichte deuten auf einen begrenzten Vorfall rund um Supportsysteme, Initialisierungscodes und missbrauchte Zertifikate hin, nicht auf kompromittierte Root- oder CA-Schlüssel ^{[1][5][10][12]}. Trotzdem ist die Konsequenz deutlich: In moderner Malware-Abwehr darf eine digitale Signatur nie das letzte Wort sein.