Атака на DigiCert через файл заставки: что она меняет для доверия к подписанному ПО

На первый взгляд это выглядело как обычный диалог с поддержкой: клиент якобы прислал скриншот проблемы. На деле ZIP-архив содержал вредоносный .scr-файл — формат, который Windows использует для экранных заставок. Согласно описанию инцидента, размещённому в Bugzilla Mozilla, злоумышленник связался с поддержкой DigiCert 2 апреля 2026 года через клиентский чат и передал такой архив под видом скриншота .

Дальше атака ударила не просто по рабочим станциям поддержки, а по более чувствительной зоне — доверию к подписи кода. По данным ThreatNoir, через скомпрометированные support-системы злоумышленники получили коды инициализации для ограниченного числа code signing-сертификатов; некоторые из них затем использовали для подписи вредоносного ПО .

Как развивалась атака

Сценарий был классическим social engineering, но с нетипично серьёзными последствиями. Help Net Security также описывает его как атаку на канал поддержки DigiCert: ZIP-файл был замаскирован под клиентский скриншот, а внутри находился вредоносный .scr-файл .

SecurityWeek сообщает, что вредоносное ПО заразило два endpoint-устройства: одно обнаружили 3 апреля, второе — 14 апреля . С одного из заражённых устройств атакующие, по этим данным, смогли перейти во внутренний портал поддержки . Там у аутентифицированных аналитиков поддержки была ограниченная функция перехода в клиентские аккаунты; через неё можно было получить доступ к отдельным операциям, включая коды инициализации для ожидающих сертификатов .

BleepingComputer уточняет важную деталь: речь шла о кодах инициализации для уже одобренных, но ещё не доставленных EV code signing-сертификатов . То есть атакующие не получили безграничный доступ ко всей инфраструктуре удостоверяющего центра, но смогли злоупотребить конкретным этапом процесса выдачи сертификатов.

Почему EV code signing так интересен атакующим

Code signing — это механизм, который помогает операционным системам, пользователям и средствам защиты оценивать происхождение и целостность программы. Если файл подписан известным издателем, он выглядит менее подозрительно, чем неизвестный бинарник без подписи. DigiCert как крупный удостоверяющий центр играет заметную роль в инфраструктуре доверия для интернет-коммуникаций и распространения ПО; его code signing-сертификаты используются разработчиками программного обеспечения .

Именно поэтому злоупотребление такими сертификатами опасно. ThreatNoir сообщает, что часть полученных сертификатов применялась для подписи malware . CyberInsider также описывает инцидент как компрометацию внутренних support-систем и данных выдачи сертификатов, позволившую получить действующие EV code signing-сертификаты, часть которых позднее использовалась для подписи вредоносного ПО .

Для атакующих EV-сертификат — это не «магический пропуск», но сильный элемент маскировки. Vectra описывает этот приём шире: злоумышленники могут подписывать вредоносные файлы EV-сертификатами, используя повышенное доверие к EV-подписанным приложениям; организации, которые полагаются только на доверие к подписи, остаются уязвимыми .

Чего этот инцидент не доказывает

Важно не преувеличивать известные факты. Доступные публичные материалы говорят о компрометации рабочих мест поддержки, внутренних support-функций и кодов инициализации сертификатов . Они не описывают компрометацию root-ключей DigiCert или ключей удостоверяющего центра.

Это не делает инцидент безобидным. Но по имеющимся данным его корректнее рассматривать не как полный захват центра сертификации, а как злоупотребление процессом поддержки и выдачи EV code signing-сертификатов .

Насколько велик был ущерб

Публичные оценки отличаются, потому что источники говорят о разных категориях сертификатов:

• ThreatNoir пишет об ограниченном числе code signing-сертификатов, часть которых использовали для подписи malware .
• Risky Business сообщает о 27 похищенных code signing-сертификатах, которые позднее применялись для подписи вредоносного ПО .
• ThreatLocker говорит о 60 отозванных code signing-сертификатах в целом .

Поэтому при чтении цифр важно смотреть, о чём именно идёт речь: о полученных сертификатах, реально использованных в атаках или отозванных в рамках реагирования. Даже если масштаб был ограниченным, риск остаётся серьёзным: для кампании с malware иногда достаточно нескольких сертификатов, которые выглядят легитимно и помогают обойти поверхностные проверки доверия .

Как последствия сдерживали

По данным BleepingComputer, DigiCert отозвала идентифицированные сертификаты в течение 24 часов после обнаружения и установила дату отзыва равной дате их выдачи . Ожидавшие заказы в затронутом временном окне были превентивно отменены . ThreatNoir также сообщает, что затронутые сертификаты отозвали в течение 24 часов, а pending orders за соответствующий период аннулировали .

Отзыв сертификатов ограничивает дальнейшее злоупотребление, но не закрывает вопрос для защитников. SOC-командам и администраторам всё равно приходится оценивать подписанные файлы по совокупности признаков: данным сертификата, хешам, поведению процесса, сетевой активности и контексту threat intelligence. EV-подпись может быть частью доверительной картины, но не её финальным доказательством .

Побочный эффект: Microsoft Defender и ложные срабатывания

Инцидент усложнился ещё и шумом вокруг Microsoft Defender. BleepingComputer сообщал, что Defender ошибочно помечал сертификаты DigiCert как Trojan:Win32/Cerdigent.A!dha . Daily.dev писал, что после обновления сигнатур 30 апреля Defender начал неверно определять легитимные root-сертификаты DigiCert как угрозу; позднее Microsoft выпустила исправление в Security Intelligence update 1.449.430.0, которое также восстанавливало удалённые сертификаты .

Для команд реагирования это создало неприятную практическую задачу: нужно было одновременно отличать реальный злоупотреблённый code signing, возможные образцы подписанного malware и ложные тревоги против легитимных сертификатов .

Что стоит вынести защитникам

Главный урок не в том, что подпись кода бесполезна. Наоборот, она остаётся важной частью цепочки доверия. Проблема в другом: подпись нельзя превращать в единственный критерий безопасности.

Практически это означает следующее:

• Не принимать подпись за автоматическое разрешение. Валидная, в том числе EV-подпись, не должна сама по себе делать файл доверенным: атакующие умеют использовать EV-сертификаты для подписи вредоносных файлов .
• Смотреть на детали сертификата. Важны издатель, серийный номер, цепочка, временная метка и статус отзыва; в случае DigiCert отзыв и привязка даты отзыва к дате выдачи были ключевыми мерами сдерживания .
• Сильнее учитывать поведение файла. Хеши, дочерние процессы, сетевые соединения, попытки закрепления в системе и результаты sandbox-анализа должны рассматриваться вместе с подписью .
• Считать support- и admin-порталы зонами высокого риска. Даже ограниченная функция поддержки может стать критичной, если через неё доступны клиентские аккаунты или коды инициализации сертификатов .
• Разбирать сертификатные алерты без паники, но быстро. История с Defender показала, что предупреждение по сертификату может быть как признаком реальной атаки, так и ложным срабатыванием после обновления сигнатур .

Итог

Атака на DigiCert показала, насколько ценным для злоумышленников остаётся доверие к подписи кода. По доступным данным, речь шла об ограниченном инциденте вокруг support-систем, кодов инициализации и злоупотреблённых EV code signing-сертификатов, а не о компрометации root- или CA-ключей . Но вывод всё равно жёсткий: в современной защите от malware цифровая подпись — это важный сигнал, а не окончательный вердикт.