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

Какую проблему решаем

Главная проблема таких атак — злоумышленники получают не просто доступ к системе, а инструмент доверия. Подписанный вредоносный файл реже вызывает подозрения у антивирусов и у самих сотрудников, особенно если он похож на обычный установщик или документ.

В этом случае исследователи связали инцидент с группой CylindricalCanine, которую считают подгруппой GoldenEyeDog. Атака началась с сообщения в канал поддержки, где жертве прислали ZIP-архив под видом скриншота, а внутри оказался исполняемый файл с вредоносной нагрузкой.

Похожий сценарий мы уже видели в разборе поддельных установщиков и чит-китов: злоумышленники почти всегда маскируют первое касание под что-то привычное и безобидное.

Что подготовить

Если вы отвечаете за ИТ или безопасность, заранее проверьте три вещи: кто может открывать вложения из внешних писем и чатов, как у вас устроен доступ техподдержки к клиентским данным и где хранятся коды подтверждения, токены и иные секреты.

Отдельно посмотрите на процессы, где сотрудник поддержки может действовать «от лица клиента». Именно такая функция в истории с DigiCert и стала слабым местом: злоумышленник использовал её, чтобы добраться до кодов оформления сертификатов.

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

Пошаговые действия

1. Закройте лишний доступ у поддержки

Проверьте, кто видит клиентские заказы, коды подтверждения и внутренние панели. Доступ должен быть минимальным: сотрудник видит только то, что нужно ему для своей задачи, а не весь путь оформления заказа.

2. Запретите запуск файлов из подозрительных вложений

Архивы, скриншоты, «счета», «акты» и «документы» из внешних источников нужно прогонять через отдельную проверку. Если файл пришёл через чат поддержки или почту, относитесь к нему так же строго, как к вложению из фишингового письма.

3. Следите за подменой установщиков

Атакующие часто прячут вредоносный модуль внутри обычной программы. В этом инциденте использовались многоступенчатые загрузчики и DLL side-loading — когда легитимный файл запускает чужую библиотеку.

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

4. Отдельно контролируйте подпись кода

Кодовые сертификаты и ключи подписи должны жить отдельно от обычных рабочих систем. Их нельзя хранить в общей папке, на машине рядового сотрудника или в панели, куда попадают по цепочке из стороннего обращения.

5. Обучите поддержку работе с «срочными» запросами

Атакующие любят давить на скорость: «посмотрите файл», «подтвердите заказ», «у нас не открывается документ». Сотрудник должен уметь остановиться и проверить источник, а не отрабатывать запрос на автомате.

Как проверить себя

Начните с простого теста. Если внешний пользователь прислал архив или ссылку, есть ли у вас отдельный маршрут проверки, или файл сразу уходит на рабочую станцию сотрудника?

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

Наконец, посмотрите на журналы. Подозрительные входы, странные прокси-сеансы, запуск неизвестных .scr или .exe из чатов и массовое обращение к внутренним страницам поддержки — всё это должно быстро попадать в разбор.

Что делать, если не получилось

Если вы уже открыли подозрительный файл, не пытайтесь «досмотреть, что внутри». Изолируйте устройство, смените пароли сервисных учётных записей и проверьте, не ушли ли токены, коды подтверждения и ключи подписи.

Если речь идёт о личном ноутбуке или рабочем ПК, не тяните с проверкой всей системы. Вредонос вроде Golden Gh0st RAT умеет не только красть данные, но и скрывать следы, снимать скриншоты, записывать клавиши и запускать дополнительные модули.

Для пользователей публичных сетей и рабочих ноутбуков полезно подключать защищённое шифрование трафика на личных устройствах, особенно если вы часто работаете вне офиса и не контролируете точку доступа.

Чек-лист

  • Проверить, кто видит коды подтверждения и клиентские заказы в системе поддержки.
  • Убрать избыточные права у сотрудников, которые не работают с сертификатами и секретами.
  • Запретить запуск вложений из чатов и внешней почты без проверки.
  • Отдельно хранить ключи подписи и кодовые сертификаты.
  • Настроить журналирование входов, запусков файлов и обращений к внутренним панелям.
  • Провести короткий инструктаж для поддержки: не открывать ZIP, SCR и EXE «на доверии».
  • Проверить, есть ли план изоляции рабочей станции после подозрительного запуска файла.
Поделиться: