Zum 3. Mai 2026 wurden eine Reihe Nutzer von Alarmen des Microsoft Defender unter Windows 11 aufgeschreckt. Der Defender hat diverse geblockte DigiCert-Zertifikate als Trojan:Win32/Cerdigent.A!dha gemeldet. Der Hintergrund ist, dass DigiCert die Tage einige Zertifikate, die von Herstellern benutzt, aber von einer chinesischen Cybergruppe missbraucht wurden, zurückgerufen (revoked) hat.
Rückblick auf das DigiCert-Zertifikate-Revoke
Vor einigen Tagen bin ich auf X über die Information gestolpert, dass DigiCert Root-Zertifikate zurückgerufen habe. Hintergrund ist, dass die chinesische Hackergruppe GoldenEyeDog (APT-Q-27) in der Lage war, EV-Zertifikate im Namen von Lenovo, Kingston, Shuttle Inc. und Palit Microsystems auszustellen und zur Signierung von Malware zu missbrauchen. Die Details sind in diesem Mozilla Bug-Report offen gelegt. Ich hatte im Blog-Beitrag EV-Zertifikate von Lenovo & Co. durch GoldenEyeDog missbraucht auf den Sachverhalt hingewiesen.
Defender blockiert Zertifikate Trojan:Win32/Cerdigent.A!dha
Mir ist das Thema in Kommentaren zum Beitrag EV-Zertifikate von Lenovo & Co. durch GoldenEyeDog missbraucht sowie per Mail zugegangen.
Eine Nutzermeldung per Mail
Stephan hat mir heute Nachmittag eine E-Mail mit dem Betreff "Trojan:Win32/ Cerdigent.A!dha: Vermutlich false positive" und der Botschaft "vielleicht interessiert Dich das hier für Deinen Blog" geschickt. Er schrieb, dass es "heute Mittag" bei Microsoft Defender-Systemen "vereinzelt rot wurde". Nach seinen bisherigen Recherchen handelt es sich vermutlich um "false positives".
Das Defender-Update 1.449.424.0 brachte laut Leser die o.g. Signatur zur Erkennung von Trojan:Win32/Cerdigent.A!dha mit, die angeblich zwei "Root-Zertifikate von DigiCert" als schädlich einstuft. Der Leser schrieb: "Ich bin mir noch nicht sicher, aber auf mich wirkt es, als ob das ein Fehler ist, den Microsoft mit Defender-Update 1.449.425.0 behoben hat. Ich beobachte das noch eine kleine Weile, gehe aber von einem Fehlalarm aus. Auf Reddit finden sich bereits einige Thread und zahlreiche Leute, die betroffen sind."
Leserkommentare hier im Blog
In diesem Kommentar schreibt Chris, dass der Defender "vor ein paar Minuten Windows Defender folgende zwei Zertifikate wegblockiert habe:
rootcert: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43rootcert: DDFB16CD4931C973A2037D3FC83A4D7D775D05E4
Es wird eine Erkennung von "Trojan:Win32/Cerdigent.A!dha" gemeldet. Das Thema werde bei reddit.com diskutiert.
Diskussionen bei Microsoft und reddit.com
Bei Microsoft Q&A gibt es seit heute den Thread Trojan:Win32/Cerdigent.A!dha, wo jemand die oben genannte Warnung thematisiert. Nachfolgend ist die Defender-Meldung aus diesem Thread zu sehen.
Zahlreiche Nutzer bestätigen den gleichen Alarm des Defender. Ein Nutzer rät, "Führen Sie Windows Update aus. Dieses Problem wurde im neuesten Microsoft-Sicherheitsdefinitionsupdate 1.449.430.0 behoben." – die Trojaner-Signatur wird nicht mehr erkannt.
Auf reddit.com finden sich z.B. dieser und dieser Thread mit der gleichen Thematik. Obiger Rückblick erklärt, warum Microsoft die beiden DigiCert-Zertifikate im Defender gesperrt hat. Die Funde gehen aber mutmaßlich in so gut wie allen Fällen nicht auf die Malware der chinesischen Hackergruppe GoldenEyeDog (APT-Q-27) zurück geht.
Sicherheitsexperte Florian Roth weist in obigem Tweet auf den gleichen Sachverhalt hin. Es bleibt aber das Problem, dass die oben genannten Zertifikate zurückgerufen wurden, und dass die chinesische Cybergruppe ihre Malware mit diesen Zertifikaten signieren konnten. Die Malware sollte erkannt werden, ohne dass andere, legitime Software, die mit den gesperrten Zertifikaten signiert wurde, nicht irrtümlich als Trojaner gemeldet wird.
Ergänzung: Die Kollegen von Bleeping Computer haben im Nachgang hier die Geschichte ebenfalls entsprechend um Informationen ergänzt.
MVP: 2013 – 2016
Moin Günter,
vielen Dank für die wie immer sehr gut aufbereiteten Infos. Hat sich gelohnt, den Rechner gestern mal ausgeschaltet gelassen zu haben ;-)
Viele Grüße und allen einen guten Start in die neue Woche,
Martin
Moin,
das war nicht das Erste und sicher nicht das Letzte mal. Je nach Schwere des Zertifikatsmissbrauchs werden Dateien, welche von Zertifikaten signiert worden, die zurückgezogen worden als 'Bedrohung' erkannt. Das ist durchaus erwünscht da die CRL Listen nur zyklisch aktualisiert werden und OCSP oft in Firmen gar nicht durch den Proxy kommt und sonmit eigentlich ungültige Zertifikate gültig bleiben. So kann man schneller reagieren als sich auf den Zertifikatsstatus zu verlassen.
Betroffene Zertifikatsnutzer werden idR rechtzeitig informiert um Updates ausrollen zu können.
"Vor einigen Tagen bin ich auf X über die Information gestolpert, dass DigiCert Root-Zertifikate zurückgerufen habe."
Das Problem ist ja, dass sich Root-Zertifikate nicht (wie untergeordnete Zertifikate) zurückrufen lassen. Root-Certs enthalten entsprechend auch keine CDP-Informationen o.Ä.. Die einzige Möglichkeit dem Root-Cert nicht mehr zu vertrauen ist also, es (auf dem Client) aus den trusted Root-CAs zu entfernen. Quasi genau das, was der Defender hier ja getan hat.
Soweit ich weiß, hat DigiCert aber auch nicht "Root-Zertifikate" zurückgerufen, sondern die (fälschlich) ausgestellten "Leaf-Zertifikate".
Ob das verhalten vom Defender jetzt "richtig" war oder nicht, sei mal dahingestellt. Ob man einer CA die fälschlicherweise EV(!)-Zertifikate an Hackergruppen ausstellt (bzw. die Ausstellung, egal auf welchem Wege, ermöglicht hat) noch vertrauen möchte, muss ja jeder selbst entscheiden. :D
Den Hashes nach wollte der Defender wirklich den Root-Zertifikaten nicht mehr vertrauen. Wie das zustande kam (naiver Praktikant oder freidrehende KI) mal außen vor, es ist schnell korrigiert worden.
Welche atomare Wirkung der Rückruf einer CA hat konnte man auch hier im Blog 2011 mit dem Rückruf der holländischen "Staat der Nederlanden Root CA – G3" sowie 2016 mit der chinesischen WoSign und israelischen StartCom sehen.
"Golden Eye Dog"
Triggert auf einem Endgerät eine eingeblendete Werbung für ….
Hundefutter in Hagen :):):).
Bin bei der "Tiernahrungskette" aber schon Kunde; hauptsächlich Vogelfutter.
Vor einiger Zeit hatte ich mal eine Zusatz-AV-Sicherheitslösung über einenRechner laufen lassen (scannt neben Viren auch auf untypische Dateigrößen etc. und andere Auffälligkeiten einschließlich den in manchen Malwaresamples enthaltenen Artefakten im Programmcode). Beim Scan schlug das Programm unter anderem bei einem bestimmtem Fachbegriff in einem WORD-Dokument (Word-Datei ohne Makros Bilder etc…) an. Das Wort kommt als Artefakt in bestimmten Malwaresamples vor. Wie es halt mit Wörtern und oder Bezeichnungen / Fachbegriffen ist, manche haben mehrere Bedeutungen (im wörtlichen, fachsprachlichen oder im übertragenem Sinn) und Kontext.
Die Kombination aus Software und Implant (mit gültigem Zertifikat) von einem "Malware-Aktoer"will wahrscheinlich keiner auf einem seiner Haupt- oder Endgeräte, es sei denn, man ist damit hauptberuflich befasst, sammelt diese und verarbeitet sie hoffentlich verantwortungsbewusst weiter.
Der Angriff erfolgte über gezippte SCR Dateien.
SCR Dateien sind ausführbar, ähnlich wie exe oder dll.
Die Crowdstrike Sicherheitssoftware hatte 4 solcher Versuche erkannt und blockiert, aber der fünfte Versuch kam durch.
siehe "Full Incident Report":
*ttps://bugzilla.mozilla.org/show_bug.cgi?id=2033170
Die Dateierweiterung ".scr" wird von verschiedenen Programmen benutzt.
Einige Beispiele sind dort aufgelistet:
*ttps://www.exefiles.com/de/extensions/scr/all-files/
Klickt man also so eine SCR Datei an, dann öffnet sich das mit dieser Dateierweiterung verknüpfte Programm und versucht die SCR-Datei auszuführen.
Falls die SCR-Datei manipuliert ist und einen Schädling enthält, dann ist das System dann infiziert.
Applocker hilft ebenfalls nicht, denn der kümmert sich normalerweise nur um ".exe", aber nicht um ".scr".
Wie schützt man sich jetzt gegen solche SCR-Dateien?
Der Defender und die CrowdStrike Sicherheitstools reichen offenbar nicht aus.
Kann man mit dem Applocker auch unbekannte ".scr" blockieren?
Haben SCR Dateien eine Signatur?
Ich glaube, das sieht nach unerwarteter Arbeit aus…
denn man muss jetzt zügig einen wirksamen Schutz gegen scr einbauen.
Auch da hatte ich einen blinden Fleck, wie vermutlich auch die meisten anderen.
Ist es sinnvoll und ohne Nebenwirkungen, wenn man die Dateierweiterung ".scr" generell blockiert?
Danke für den Link zum Incident-Report. Spannend zu Lesen. Mein Fazit daraus:
– "Hinterher ist man immer schlauer".
– Dass soviele Fehler gleichzeitig vorlagen – und dass in einer Profi-IT-Organisation (?) – lässt erschaudern.
– Schön, dass Digicert auch die "Glück-gehabt"-Begebenheiten beschreibt. Hätten Sie Pech gehabt, wär der Schaden noch größer.
– Man kann nur verlieren gegen die Hacker :-(
Die Windows-Screensaver mit ".scr" Dateierweiterung im System32- und SYSWOW64-Ordner haben keine Signatur.
Diese Dateien haben aber eine "MZ"-Kennung am Dateianfang, genauso wie eine EXE Datei und ebenso den üblichen EXE-Header.
SCR sind also im Grunde nur umbenannte EXE Dateien und damit hochgefährlich, wenn man diese nicht sperrt.
Wegen der fehlenden Signatur bei den erwünschten und vom OS mitgelieferten Dateien ist es umso schlimmer.
Generelles Sperren von SCR geht aber auch nicht, weil SCR nicht nur von Screensavern benutzt wird, sondern zum Beispiel auch von AutoCAD.
Man müsste also im Applocker SCR sperren, aber dann in der selben Regel die Ausnahmen-Liste füllen mit den erlaubten und erwünschten SCR Dateien.
Im Datei-Dialog der Ausnahmen-Liste im Applocker ist als Auswahlmöglichkeit aber auch nur .exe und .com auswählbar, aber kein .scr oder sonstige Dateierweiterungen.
Da muss man wieder händisch basteln ("*.scr" als Dateiname vorgeben), weil Microsoft mal wieder nicht mitgedacht hat.
Obendrein kann man bei der Dateiauswahl auch kein Shift drücken, um mehrere Dateien gleichzeitig auszuwählen, wenn man als Dateiname "*.scr" vorgegeben hat und alle gewünschte Dateien angezeigt werden.
Da muss man dann jede Datei einzeln auswählen und eintragen und den Dialog für jede Datei erneut öffnen, weil Microsoft mal wieder nicht mitgedacht hat.
Wenn man dann eine SCR Datei angeklickt hat in den Ausnahmen des Applocker, dann wird dort erstaunlicherweise doch der Herausgeber angezeigt, also ein Teil des Zertifikats, welches man aber im Explorer-Dateidialog (Rechtsklick, Eigenschaften) nicht angezeigt bekommt, da der Reiter "Signatur" fehlt.
Windows wird mit jedem Tag unwartbarer.
Bald ist Windows wirklich reif für die Mülltonne.
Ich habe jetzt generell alle "*.scr" im Applocker gesperrt und alle 6 erwünschten SCR (mitgelieferte Windows-Screensaver im SYSTEM32) als Ausnahmen hinzugefügt.
Im Grunde werden also nur diese 6 SCR Dateien in eine Whitelisting-Regel eingetragen und alle anderen SCR geblacklistet.
Bei einem Test wurden außerhalb von SYSTEM32 gespeicherte Screensaver-SCR erfolgreich blockiert.
Manche werden zwar meinen, man bräuchte solche aufwändigen Regeln gar nicht, weil Applocker generell mit Whitelisting arbeitet, aber meine Erfahrungen mit Applocker sind nunmal andere.
Ich habe auch die Temp-Ordner und Desktop-Ordner ausdrücklich und auch für Administratoren gesperrt, was eigentlich nicht nötig sein müsste, aber nur so werden unerwünschte Installationen unmöglich gemacht. Außerdem sind die alternativen Datenströme für diverse Unterordner von Windows und Programm-Ordnern gesperrt.
Die Ursache für diesen zusätzlichen Aufwand ist die Applocker-Standardregel "Alle Dateien zulassen für Administratoren".
Diese Regel will ich nicht auf "zulassen für System" ändern (wie es Mark Heitbrink bei sich macht), also muss ich explizit zusätzliche Ordner sperren und Regeln erzeugen.
Ich bin mir sicher, dass viele Admins in ihrem Applocker Lücken haben, die fast nie auffallen, bis es zu spät ist.
Da ich auch einige Zertifikate gesperrt bzw erlaubt habe für Dateien, die außerhalb der Programme-Ordner liegen, bin ich jetzt bei über 100 Regeln angelangt und nur so läuft das System sicher und gut.
Dank dieses Regelaufwands sind mir auch schon falsch programmierte Programme aufgefallen, wie etwas GPU-Z, die den Temp-Ordner missbrauchen wollen, um zusätzliche Threads zu starten, was der Applocker dann verhindert. Solche Dropper sind hier unerwünscht, egal ob bösartig oder gutartig.
@Bolko
Entschuldige die vielleicht etwas ungewöhnliche Frage:
Da Du Dich mit Applocker sehr gut auskennst, gibt es Anleitungen, welche das Einrichten verständlich beschreiben?
Ich habe bisher mit SRP und Applocker keine Berührungen gehabt. Und möchte mich, damit ganz gerne näher beschäftigen. Um das evtl. auch bei uns einzuführen.
Vielen Dank für Deine Rückmeldung.
Ich habe hier im Blog selber schon zwei mal Anleitungen zum Applocker geschrieben (Januar 2025), aber wie ich letztens feststellen musste, waren meine Anleitungen immer noch unvollständig.
Danke an Stefan Kanthak für seine Hinweise zu den alternativen Streams (*2) und jetzt der fehlende Schutz gegen SCR-Dateien.
Anleitung zum Applocker siehe dort und Folgebeiträge:
*ttps://www.borncity.com/blog/2025/01/13/billig-aliexpress-china-rj45-adapter-mit-sypware-oder-treiber-installer/#comment-205309
Die dort angegeben Regeln sind aber noch unvollständig.
(*2):
*ttps://borncity.com/blog/2026/01/18/windows-applocker-richtlinien-mit-wenigen-handgriffen-installieren/
Eine weiter verbesserte Anleitung müsste ich demnächst mal schreiben und meine Applocker-Regeln irgendwo hochladen.
Windows ohne Applocker-Schutz ist offen wie ein Scheunentor und von einem kundigen Angreifer innerhalb von Minuten oder gar Sekunden geknackt.
Leider hat Microsoft die Applocker-Funktion alles andere als intuitiv gestaltet und mehrere Fallstricke eingebaut.
Ist hier auch aufgelaufen. Die Meldung im Microsoft 365 Defender wurde aber bereits durch das "Defender Team" als "Falsch positiv" und "gelöst" markiert.
Der Vorfall bei DigiCert geschah also bereits am 2. und 3.April, laut dem Report (*1):
"detection (2026-04-03)"
Erst am 14.April hat man gemerkt bzw bestätigt, dass auf dem Computer "Endpoint2" die CrowdStrike EDR Sensoren gar nicht aktiv waren:
"2026-04-14 ~20:35 CrowdStrike support confirms ENDPOINT2 sensor gap"
Normalerweise hätte es einen automatischen Alarm geben müssen, wenn bei einem EDR-System die Sensoren nicht antworten.
War der Angreifer in der Lage das CrowdStrike-EDR-System abzuschalten?
Endpoint1 hatte man zwar frühzeitig als infiziert erkannt und aus dem Verkehr gezogen, aber Endpoint2 nicht.
"ENDPOINT2 is not considered compromised."
Theoretisch hätte der Angreifer aber auch auf dem Endpoint2 Computer aktiv sein können, aber das hat man wegen der abgeschalteten EDR Sensoren halt gar nicht gemerkt. Es wurden jedenfalls auf dem email-Empfangs-Server zahlreiche weitere ebenfalls infizierte ZIPs gefunden, bevor diese gestartet werden konnten.
Eventuell hat man auch einige dieser ZIPs bereits an Endpoint2 weitergeleitet und dort gestartet, ohne dass ein Alarm ausgelöst wurde.
Wenn Endpoint2 infiziert war und der Angreifer hinterher gründlich aufgeräumt hat, dann weiß man immer noch nicht, was dort passiert ist.
2.
27 plus 33 Zertifikate sollen betroffen sein, also in Summe 60 Stück.
"In addition to the 27 identified above, 33 of the 60 total certificates were revoked"
Heise meldet aber inzwischen 61 Zertifikate:
"Insgesamt umfasst die von DigiCert gemeldete Liste 61 Zertifikate"
*ttps://www.heise.de/news/Nach-Malware-Angriff-Kriminelle-nutzten-Codesigning-Zertifikate-von-DigiCert-11280757.html
Hoffentlich hat man dieses eine Zertifikat nicht vergessen zu sperren.
Aber nein, es ist anders:
Heise ist zu blöd zum Lesen oder zum Zählen.
Wenn man sich aus Quelle (*1) ganz unten im Appendix das Attached File mit der Liste der Zertifikate runterlädt:
"Bugzilla_2033170_Appendix.csv", dann sieht man, dass es 60 Stück Zertifikate sind plus in Zeile 1 die Spaltenüberschriften, die Heise mitgezählt hat.
Es sind also nicht 61 Zertifikate, sondern 60 und Heise hat einen Fehler im Artikel.
(*1):
*ttps://bugzilla.mozilla.org/show_bug.cgi?id=2033170
3.
Warum hat Microsoft erst am 30.April reagiert und sperrte dann auch noch die beiden falschen Zertifikate statt die 60 richtigen Zertifikate?
Wurde Microsoft von DigiCert gar nicht informiert oder wie ist so eine Verzögerung zu erklären?
SCR-Dateien dauerhaft über die Windows-Eingabeaufforderung deaktivieren:
assoc .scr=txtfile