Сценарий был классическим social engineering, но с нетипично серьёзными последствиями. Help Net Security также описывает его как атаку на канал поддержки DigiCert: ZIP-файл был замаскирован под клиентский скриншот, а внутри находился вредоносный .scr-файл .
SecurityWeek сообщает, что вредоносное ПО заразило два endpoint-устройства: одно обнаружили 3 апреля, второе — 14 апреля . С одного из заражённых устройств атакующие, по этим данным, смогли перейти во внутренний портал поддержки . Там у аутентифицированных аналитиков поддержки была ограниченная функция перехода в клиентские аккаунты; через неё можно было получить доступ к отдельным операциям, включая коды инициализации для ожидающих сертификатов .
BleepingComputer уточняет важную деталь: речь шла о кодах инициализации для уже одобренных, но ещё не доставленных 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-сертификатов .
Публичные оценки отличаются, потому что источники говорят о разных категориях сертификатов:
Поэтому при чтении цифр важно смотреть, о чём именно идёт речь: о полученных сертификатах, реально использованных в атаках или отозванных в рамках реагирования. Даже если масштаб был ограниченным, риск остаётся серьёзным: для кампании с malware иногда достаточно нескольких сертификатов, которые выглядят легитимно и помогают обойти поверхностные проверки доверия .
По данным BleepingComputer, DigiCert отозвала идентифицированные сертификаты в течение 24 часов после обнаружения и установила дату отзыва равной дате их выдачи . Ожидавшие заказы в затронутом временном окне были превентивно отменены . ThreatNoir также сообщает, что затронутые сертификаты отозвали в течение 24 часов, а pending orders за соответствующий период аннулировали .
Отзыв сертификатов ограничивает дальнейшее злоупотребление, но не закрывает вопрос для защитников. SOC-командам и администраторам всё равно приходится оценивать подписанные файлы по совокупности признаков: данным сертификата, хешам, поведению процесса, сетевой активности и контексту threat intelligence. EV-подпись может быть частью доверительной картины, но не её финальным доказательством .
Инцидент усложнился ещё и шумом вокруг 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 и ложные тревоги против легитимных сертификатов .
Главный урок не в том, что подпись кода бесполезна. Наоборот, она остаётся важной частью цепочки доверия. Проблема в другом: подпись нельзя превращать в единственный критерий безопасности.
Практически это означает следующее:
Атака на DigiCert показала, насколько ценным для злоумышленников остаётся доверие к подписи кода. По доступным данным, речь шла об ограниченном инциденте вокруг support-систем, кодов инициализации и злоупотреблённых EV code signing-сертификатов, а не о компрометации root- или CA-ключей . Но вывод всё равно жёсткий: в современной защите от malware цифровая подпись — это важный сигнал, а не окончательный вердикт.