3 мая 2026 года пользователи Windows 11 и Windows Server по всему миру столкнулись с массовыми срабатываниями Microsoft Defender, который начал помечать как высокоприоритетную угрозу Trojan:Win32/Cerdigent.A!dha легитимные корневые сертификаты DigiCert. Проблема затронула как домашние ПК, так и корпоративную инфраструктуру с Microsoft Defender for Endpoint и Defender XDR.
Источник проблемы – обновление сигнатур Microsoft Defender версии 1.449.424.0, выпущенное 3 мая 2026 года в 09:03:46 (по данным официального списка изменений Microsoft Security Intelligence). Сразу после его установки антивирус начал детектировать в системном хранилище сертификатов Windows два корневых центра сертификации DigiCert и помещать их в карантин с пометкой «обнаружена вредоносная программа высокой степени серьёзности».
Сигнатура Trojan:Win32/Cerdigent.A!dha в этом обновлении значится в разделе «Updated threat detections» – это не новое правило, а обновлённая версия уже существующей сигнатуры. Вместе с ней Microsoft обновила и сигнатуры семейства Trojan:Win32/Malgent, ориентированные на бинарники, подписанные подозрительными или скомпрометированными сертификатами.
Какие сертификаты затронуло ложное срабатывание
По данным сообщества безопасности и публикаций в Reddit и соцсети X, Defender ошибочно реагирует на два корневых сертификата DigiCert с следующими отпечатками SHA-1:
DDFB16CD4931C973A2037D3FC83A4D7D775D05E4– DigiCert Trusted Root G40563B8630D62D75ABBC8AB1E4BDFB5A899B24D43– DigiCert Assured ID Root CA
На скомпрометированных машинах эти сертификаты лежат в реестре Windows в подразделах хранилища SystemCertificates. По данным отчёта администратора в Microsoft Q&A Defender удалил ключи по двум путям:
HKLM\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates\DDFB16CD4931C973A2037D3FC83A4D7D775D05E4 HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates63B8630D62D75ABBC8AB1E4BDFB5A899B24D43
На конкретной машине пути могут отличаться – один и тот же сертификат может быть зарегистрирован одновременно в подразделах ROOT, AuthRoot и Policies\Microsoft\SystemCertificates\root, и Defender удаляет записи в зависимости от того, где они присутствуют. В журнале событий действие фиксируется как MALWAREPROTECTION_MALWARE_ACTION_TAKEN от процесса MsMpEng.exe, выполняющегося под NT AUTHORITY\SYSTEM.
Удаление этих корневых сертификатов нарушает работу проверки подписи у большой части сайтов и приложений: подписанное ПО, обновления Windows, TLS-соединения с внутренними сервисами и многое другое полагается на цепочку доверия от DigiCert.
Почему это ложное срабатывание, а не реальный троян
Несмотря на пугающую формулировку «Trojan» и высокий уровень серьёзности, признаков реального заражения нет:
- Срабатывание происходит одновременно у тысяч пользователей по всему миру в один и тот же день – характерный признак ошибки в сигнатурах, а не вредоносной кампании.
- Defender не указывает конкретный путь к файлу или хеш бинарника – детект идёт исключительно по записям реестра с отпечатками сертификатов.
- Хеши совпадают с официально опубликованными корневыми сертификатами DigiCert (DigiCert Trusted Root Authority Certificates).
- Сторонние антивирусы – Malwarebytes, SentinelOne, Arctic Wolf – на этих машинах ничего не обнаруживают.
- Проверка через VirusTotal по отпечаткам сертификатов также не даёт ни одного срабатывания.
На GitHub уже опубликован репозиторий Cerdigent с KQL-запросом для Defender XDR Advanced Hunting, который позволяет отделить ложные срабатывания этого инцидента от реальных событий и оценить масштаб шума в корпоративных тенантах.
Microsoft уже выпустила исправление
Microsoft не опубликовала официального заявления, однако исправление пришло через стандартный механизм обновления сигнатур. По сообщениям пользователей и администраторов:
- Версия сигнатур 1.449.430.0 уже не помечает сертификаты DigiCert как вредоносные.
- В Microsoft Defender XDR корневые сертификаты автоматически возвращаются в системное хранилище при следующей синхронизации – на корпоративных машинах процесс восстановления уже идёт.
- На домашних ПК после установки актуальных сигнатур повторное сканирование проходит чисто.
Промежуточные версии 1.449.424.0 и 1.449.425.0 содержат ошибочную сигнатуру.
Что делать пострадавшим
Если Microsoft Defender уже поместил сертификаты в карантин:
- Открыть «Безопасность Windows» > «Защита от вирусов и угроз» > «Обновления защиты» и нажать «Проверить наличие обновлений». Убедиться, что установлена версия сигнатур 1.449.430.0 или новее.
- Перейти в «Журнал защиты», найти записи о
Trojan:Win32/Cerdigent.A!dhaи нажать «Восстановить». Сертификаты вернутся в системное хранилище. - Запустить быстрое сканирование повторно – срабатываний быть не должно.
Если по каким-то причинам обновление ещё не пришло, на сайте Microsoft Security Intelligence можно вручную скачать актуальный пакет сигнатур (mpam-fe.exe) и установить его до автоматического обновления.
Полная переустановка Windows в этом случае бессмысленна – на чистой системе сертификаты DigiCert присутствуют изначально, и Defender со старыми сигнатурами тут же снова поставит их в карантин. Достаточно дождаться обновления сигнатур.
Что делать, если сертификаты уже удалены из карантина
Если вы удалили угрозу или очистили карантин и восстановить сертификаты через журнал защиты не получается — их можно вернуть несколькими способами.
Способ 1. Скачать новые корневые сертификаты с серверов Windows Update
Сертификаты можно получить напрямую с серверов Microsoft. Команду нужно запускать в командной строке или PowerShell от имени администратора:
certutil -generateSSTFromWU C:\roots.sst
Команда скачивает с Windows Update актуальный набор корневых сертификатов от Microsoft Trusted Root Program и сохраняет их в файл roots.sst. В этом наборе присутствуют все корневые сертификаты DigiCert, в том числе DigiCert Trusted Root G4 и DigiCert Assured ID Root CA.
Дальше файл нужно импортировать в системное хранилище. Открыть PowerShell от имени администратора и выполнить:
Get-ChildItem -Path C:\roots.sst | Import-Certificate -CertStoreLocation Cert:\LocalMachine\Root
После импорта сертификаты появятся в хранилище Доверенные корневые центры сертификации. Перезагрузка не требуется.
Способ 2. Восстановление через точку восстановления системы
Если на компьютере включена защита системы и есть точка восстановления, созданная до 3 мая 2026 года — откат к ней вернёт записи реестра и сертификаты на место.
- «Панель управления» > «Система» > «Защита системы» > «Восстановление системы».
- Выбрать точку, созданную ранее даты инцидента.
- После завершения отката обязательно сразу обновить базы Microsoft Defender до 1.449.430.0, иначе сценарий повторится.
Способ 3. Импорт вручную с сайта DigiCert
Запасной вариант на случай, если первые два не сработали. На официальной странице DigiCert найти сертификаты DigiCert Trusted Root G4 и DigiCert Assured ID Root CA, рядом с каждым нажать ссылку Download и скачать в формате DER — это родной для Windows бинарный формат с расширением .crt.
Установить каждый файл двойным щелчком, в мастере выбрать «Поместить все сертификаты в следующее хранилище» > «Доверенные корневые центры сертификации». Подтвердить запрос UAC и предупреждение о добавлении корневого сертификата.
На корпоративных машинах под управлением Microsoft Defender for Endpoint и Defender XDR ничего делать не нужно — корневые сертификаты автоматически возвращаются в системное хранилище при следующей синхронизации с облачной службой.
Откуда взялась сигнатура Cerdigent
Cerdigent ловит активность, связанную с инцидентом компрометации в DigiCert. Полный отчёт опубликован в Bugzilla 2033170 и содержит детальную хронологию атаки на службу поддержки центра сертификации.
- 2 апреля 2026: атакующий связался со службой поддержки DigiCert через чат Salesforce и под видом скриншотов отправил ZIP-архивы с исполняемым файлом
.scrвнутри. Четыре попытки доставки заблокировал CrowdStrike, пятая скомпрометировала рабочую станциюENDPOINT1аналитика поддержки. Среди запущенных бинарников отчёт упоминаетk3.exe,updat.exe,uuu.exe,VideoManager.exe. - 3 апреля 2026: команда Trust Operations DigiCert обнаружила инцидент через срабатывания CrowdStrike, изолировала
ENDPOINT1, удалила вредоносные процессы и записи реестра. Расследование на этом этапе сочло инцидент локализованным. - 4 апреля 2026: через тот же вектор был скомпрометирован
ENDPOINT2второго аналитика. Из-за неработающего датчика CrowdStrike на этой машине компрометация осталась незамеченной до 14 апреля. Атакующий получил доступ к внутреннему саппорт-порталу и через функцию proxy-доступа к учётным записям клиентов начал извлекать коды инициализации (initialization codes) для одобренных, но ещё не выданных EV Code Signing сертификатов. Authentication-сессия Okta FastPass с скомпрометированной машины удовлетворяла требования MFA без второго фактора. - 5 апреля 2026: DigiCert получила первый отчёт от стороннего исследователя о подозрительном сертификате.
- 5–14 апреля 2026: на DigiCert поступали повторяющиеся отчёты о сертификатах, использованных для подписи вредоносного ПО. Поначалу они проходили как стандартные certificate problem reports, без связки в общий инцидент.
- 14 апреля 2026: Support Leadership подключила Trust Operations к расширенному расследованию. Был обнаружен пробел в покрытии CrowdStrike на
ENDPOINT2и факт его компрометации. В этот же день DigiCert замаскировала коды инициализации в proxy-сессиях саппорт-портала (UI-уровень) и отключила Okta FastPass для портала. - 14–17 апреля 2026: отозваны 60 сертификатов подписи кода, выпущенных через промежуточные центры DigiCert Trusted G4 Code Signing RSA4096 SHA256 2021 CA1, SHA384 2021 CA1, а также GoGetSSL G4 CS RSA4096 SHA256 2022 CA-1 и Verokey High Assurance Secure Code EV. 27 из них явно связаны с действиями атакующего, ещё 33 отозваны как мера предосторожности.
Отозванные сертификаты использовались для подписи вредоносного ПО семейства Zhong Stealer – это подтверждено в самом отчёте DigiCert. Список IP-адресов, с которых атакующий устанавливал сертификаты: 82.23.186.8, 154.12.185.32, 45.144.227.12, 203.160.68.2, 154.12.185.30, 62.197.153.45, 45.144.227.29.
Сигнатура Trojan:Win32/Cerdigent.A!dha, судя по всему, была обновлена именно в ответ на этот инцидент – 3 мая 2026 года, в составе обновления 1.449.424.0. Задумка понятная: заблокировать всё, что было подписано отозванными сертификатами. На практике правило получилось слишком общим и затронуло не скомпрометированные сертификаты подписи кода, а корневые сертификаты DigiCert, от которых эта самая подпись и проверяется.
Это уже не первый случай, когда сигнатурный движок Defender ошибочно реагирует на легитимный код. Текущий инцидент с Cerdigent отличается масштабом – сертификаты DigiCert установлены практически на всех Windows-системах, поэтому ложное срабатывание стало глобальным в течение нескольких часов после выхода обновления 1.449.424.0.
Для крупных тенантов Microsoft Defender for Endpoint рекомендуется временно добавить отпечатки DDFB16CD4931C973A2037D3FC83A4D7D775D05E4 и 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43 в исключения, если есть риск повторных срабатываний на машинах, которые ещё не получили версию 1.449.430.0.