Цифровой сертификат, прикреплённый к исполняемому файлу, подтверждает, что код pochodёт от заявленного издателя и не был изменён после подписи. Если сертификат выглядит подозрительно — например, самоподписанный, от неизвестного центра сертификации, просроченный или отозванный — это может сигнализировать о вредоносном или недоверенном ПО. Ниже описано, как проверить сертификат любого запущенного процесса в Windows и на что обращать внимание.
Что такое цифровой сертификат процесса и зачем его проверять
При запуске программы Windows может проверить её цифровую подпись, если файл содержит блок Authenticode. Подпись включает:
- хэш файла, зашифрованный закрытым ключом издателя;
- сертификат открытого ключа, привязанный к издателю;
- временную метку (timestamp), подтверждающую, что подпись была действительна в момент её создания.
Если подпись верна, система доверяет файлу как originating от проверенного издателя. Подозрительный сертификат нарушает эту цепочку доверия и может указывать на:
- использование украденного или скомпрометированного ключа;
- самоподписанный сертификат, созданный злоумышленником;
- сертификат, выпущенный центром, не включённым в доверенные корневые хранилища Windows;
- просроченный или отозванный сертификат.
Основные признаки подозрительного сертификата
При визуальном анализе сертификата обращайте внимание на следующие пункты:
- Неизвестный или самоподписанный издатель. Если в поле «Издатель» указано имя, которого нет в списке доверенных корневых центров, либо поле пустое — это тревожный сигнал.
- Отсутствие цепочки доверия к корневому центру. Сертификат должен вести к одному из корневых сертификатов, встроенных в Windows (например, Microsoft Root Certificate Authority). Если цепочка обрывается — сертификат не доверен.
- Срок действия истёк или ещё не наступил. Проверяйте даты «Начало действия» и «Окончание действия». Просроченный сертификат уже не обеспечивает целостности подписи.
- Отзыв сертификата (CRL/OCSP). Даже если срок не истёк, центр сертификации мог отозвать сертификат из‑за компрометации ключа.
- Неправильное назначение ключа (EKU). Для подписи кода обязателен расширенный ключ использования «Подпись кода» (1.3.6.1.5.5.7.3.3). Если его нет — подпись не предназначена для проверки исполняемых файлов.
- Несоответствие хэша файла и подписи. Если после проверки подписи хэш вычисляется иначе, файл был изменён после подписи.
- Подозрительные свойства субъекта. Имя субъекта может содержать случайные символы, быть слишком длинным или имитировать известное название компании с небольшими изменениями (например, «Micr0s0ft» вместо «Microsoft»).
Инструменты для проверки цифровой подписи процесса
В Windows есть несколько встроенных и свободно распространяемых утилит, которые позволяют быстро получить информацию о сертификате, привязанном к исполняемому файлу процесса.
- PowerShell. Командлет Get-AuthenticodeSignature возвращает статус подписи, информацию о сертификате и цепочке доверия.
- Sigcheck (Sysinternals). Утилита sigcheck.exe -q -m <путь> выводит сведения о подписи, включая дату timestamp и проверку цепочки.
- Certutil. Команда certutil -verify <файл> выполняет проверку подписи и цепочки, а также может проверить статус отзыва через CRL.
- Process Explorer (Sysinternals). В окне свойств процесса есть вкладка «Image» → «Verified Signer», где отображается статус подписи и детали сертификата.
- Windows Defender ATP / Microsoft Defender for Endpoint. В корпоративной среде можно получить автоматическое оповещение о процессах с неподписанными или подозрительно подписанными образами.
Пошаговая проверка процесса
Ниже представлен универсальный алгоритм, который можно выполнить на любой рабочей станции с правами обычного пользователя (для некоторых шагов может потребоваться запуск от имени администратора).
- Определите PID и путь к образу процесса. Откройте Диспетчер задач, найдите подозрительный процесс, щёлкните правой кнопкой → «Перейти к сведениям», затем в колонке «Образ пути» скопирите полное расположение файла (например, C:\Users\Public\svchost.exe).
- Проверьте файл на наличие подписи через PowerShell. Запустите PowerShell и выполните:
Get-AuthenticodeSignature -FilePath «C:\Путь\к\файлу.exe»
Обратите внимание на поле Status (Valid, UnknownError, NotSigned, HashMismatch и т.д.) и на список сертификатов в SignerCertificate. - Выведите детали сертификата. Если подпись присутствует, получите её серийный номер и запустите:
$cert = (Get-AuthenticodeSignature -FilePath «C:\Путь\к\файлу.exe»).SignerCertificate
$cert | Format-List *
Изучите поля: Subject, Issuer, NotBefore, NotAfter, Extensions (особенно EnhancedKeyUsage и CertificatePolicies). - Проверьте цепочку доверия. Выполните:
certutil -verify -urlfetch «C:\Путь\к\файлу.exe»
В выводе ищите строки «Chain verification» и «Revocation Status». Если цепочка обрывается или статус отзыва — «Revoked» или «Offline», это повод для насторожённости. - Определите назначение ключа. В расширении EnhancedKeyUsage должно присутствовать OID 1.3.6.1.5.5.7.3.3 (Code Signing). Если его нет — подпись не предназначена для проверки исполняемого кода.
- Сравните хэш файла и подписи. Утилита sigcheck -q -h <путь> покажет вычисленный хэш и хэш, зашифрованный в подписи. Несовпадение указывает на изменение файла после подписи.
- Оцените репутацию издателя. Скопируйте субъект сертификата (поле Subject) и проверьте его в поисковике или в базах известных издателей. Если имя незнакомое, содержит опечатки или выглядит случайно сгенерированным — повысьте уровень подозрения.
Что делать, если сертификат действительно подозрителен
Обнаружение одного из признаков не всегда означает, что процесс вредоносный, но требует дальнейших действий:
- Изолируйте процесс. При помощи Диспетчеров задач или Process Explorer приостановите выполнение процесса (опция «Suspend»), чтобы предотвратить возможный вред, пока проводится дальнейшее исследование.
- Соберите образ файла для анализа. Скопируйте исполняемый файл в изолированную карантинную папку (например, на внешний носитель, отключённый от сети) и вычислите его хеш SHA‑256 для последующего сравнения с базами угроз.
- Запустите антивирусный сканер. Передайте файл на проверку несколькими движками (например, через онлайн‑сервисы VirusTotal или локальные антивирусные решения с обновлёнными базами).
- Проверьте автозагрузку и связанные артефакты. Используйте Autoruns (Sysinternals) чтобы увидеть, из какого места в реестре или планировщика задач запущен процесс. Удалите или отключите запись, если она выглядит подозрительно.
- Обновите списки отзыва и корневые центры. Убедитесь, что система получила последние обновления Windows Update, включая обновления корневых сертификатов и списки отзыва (CRL). Это снижает шанс ложного срабатывания из‑за устаревших данных.
- При необходимости обратитесь к специалисту по безопасности. Если после базовых проверок остаются сомнения, передайте собранные артефакты (файл, дамп памяти, логи) в службу incident response или к внешнему эксперту.
Ограничения и ложные срабатывания
Некоторые легитимные программы могут вызывать ложные тревоги при проверке сертификатов:
- Внутренние корпоративные приложения часто подписываются сертификатами, выпущенными внутренним центром сертификации организации, который не входит в стандартные доверенные корневые хранилища Windows. В таких случаях цепочка доверия будет обрываться, но это ожидаемо для внутренней инфраструктуры.
- Тестовые или отладочные сборки могут быть подписаны самоподписанными сертификатами для удобства разработки. Их наличие в продакшн‑среде следует рассматривать как нарушение политики, но не обязательно как вредоносность.
- Некоторые легитимные вендоры используют сертификаты с коротким сроком действия (например, 90 дней) и регулярно обновляют их. Если вы проверяете файл сразу после выпуска обновления, старый сертификат может уже быть просрочен, а новый — ещё не распространён в кэше CRL.
- Упаковщики и защищающие оболочки (packers, crypters) иногда удаляют или заменяют блок подписи, оставляя только заголовок. В этом случае подпись будет отсутствовать, а не подозрительной — всё равно требует внимания, так как отсутствие подписи само по себе может быть признаком подмены.
Поэтому окончательный вывод следует делать, учитывая контекст: источник файла, наличие цифровой подписи в политике организации, поведение процесса (сетевые подключения, модификация реестра, доступ к файлам) и результаты антивирусного сканирования.
Практический итог
Главный принцип: доверяйте только тем исполняемым файлам, чья цифровая подпись образует полную, неповреждённую цепочку доверия к корневому центру, имеет правильное назначение ключа (Code Signing), не отозвана и не просрочена. Любое отклонение от этого правила — повод для более глубокого анализа.
Конкретные следующие шаги после обнаружения подозрительного сертификата:
- Приостановите процесс и изолируйте его исполняемый файл.
- Проверьте подпись с помощью PowerShell или Sigcheck, запишите статус и детали сертификата.
- Убедитесь в целостности цепочки доверия и проверьте статус отзыва через certutil.
- Сравните хеш файла и подписи, оцените назначение ключа и репутацию издателя.
- При подтверждении подозрения — отправьте файл на антивирусный анализ, проверьте автозагрузку и, при необходимости, вовлеките службу безопасности.
Если после всех проверок признаки подозрения не подтвердились, но файл всё ещё вызывает сомнения (например, неизвестный издатель, необычное поведение), продолжайте мониторинг и рассмотрите возможность добавления правила блокировки в политики контроля приложений (AppLocker, Windows Defender Application Control) до получения дополнительной информации.