Как проверить EXE-файл перед запуском: пошаговая инструкция безопасности

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

Почему антивирус на компьютере — этого недостаточно

Резидентный антивирус сканирует файлы при обращении к диску. Но он работает по сигнатурам и эвристике, которые известны на момент обновления баз. Новые вредоносные образцы (zero-day), полиморфный код, упакованные исполнимые файлы и «живые» загрузчики, скачивающие полезную нагрузку уже после запуска, часто проходят эту линию обороны. Плюс антивирус не проверит соответствие файла тому, что публиковал разработчик — он лишь ищет известные признаки зла.

Следовательно, многослойная проверка до первого запуска снижает риск компрометации системы на порядки. Ниже — иерархия методов от самых быстрых к трудоёмким, но информативным.

Подготовка: изоляция и бэкап

Перед любой проверкой подозрительного файла создайте условия, где ошибка не станет катастрофой:

• Рабочая виртуальная машина — идеальный полигон. VirtualBox, VMware Workstation Player или Hyper-V с чистой ОС и снапшотом «до проверки». После анализа просто откатитесь.
• Песочница Windows (Windows Sandbox) — встроенная в Pro/Enterprise редакции Windows 10/11 лёгкая изолированная среда. Запускается за секунды, при закрытии всё стирается. Подходит для быстрой динамической проверки.
• Отдельный физический компьютер / старый ноутбук — если виртуализация недоступна. Никаких личных данных, паролей, криптокошельков.
• Отключение сети — для статического анализа и запуска в песочнице лучше отключить интернет, чтобы вредонос не «дозвонился» до C2-сервера и не скачал вторую стадию.
• Снапшот системы или образ диска — если проверяете на основной ОС (не рекомендуется), заранее создайте точку восстановления или образ раздела (Macrium Reflect, Clonezilla).

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

Шаг 1. Проверка хеш-суммы (SHA-256 / SHA-1 / MD5)

Самый быстрый способ убедиться, что файл не был изменён при загрузке — сравнить его хеш с эталонным, опубликованным разработчиком на официальном сайте, в GitHub Releases, в заметках к релизу или в реестре пакетов (Chocolatey, Scoop, winget).

Как считать хеш в Windows (PowerShell):

1. Откройте PowerShell (Win+X → Windows PowerShell).
2. Выполните: Get-FileHash -Algorithm SHA256 «C:\путь\к\файлу.exe»
3. Сравните вывод с эталоном (регистр не важен).

В командной строке (certutil):

1. certutil -hashfile «C:\путь\к\файлу.exe» SHA256

В Linux / macOS / WSL:

1. sha256sum файл.exe или shasum -a 256 файл.exe

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

Шаг 2. Многосканерные онлайн-проверки (VirusTotal, Hybrid Analysis, MetaDefender)

Загрузка файла на VirusTotal или аналогичные сервисы прогоняет его через 60–70 антивирусных движков одновременно. Это эвристический и сигнатурный скрининг за 10–30 секунд.

• VirusTotal.com — де-факто стандарт. Поддерживает файлы до 650 МБ. Показывает детекты каждого движка, поведение в песочнице, сетевые индикаторы (IP, домены), строки внутри файла, импорт/экспорт таблицы PE.
• Hybrid Analysis (hybrid-analysis.com) — глубокий динамический анализ в песочнице с отчётом о системных вызовах, создании файлов, ключах реестра, сетевом трафике, MITRE ATT&CK тегами.
• MetaDefender (metadefender.opswat.com) — ещё один мультисканер с акцентом на корпоративные угрозы.
• Any.Run (any.run) — интерактивная песочница: можно посмотреть видео выполнения, кликнуть, ввести пароль, если вредонос ждёт взаимодействия.

Важные нюансы:

• Загрузка файла на публичный сервис делает его доступным исследователям и, потенциально, злоумышленникам. Если файл содержит коммерческую тайну, личные данные или является проприетарным инструментом — не загружайте его на публичные сканеры. Используйте локальные инструменты (см. ниже).
• Отсутствие детектов чистота. Новые образцы часто имеют 0/70 на VirusTotal. Обратите внимание на вкладку «Behavior» / «Relations» — там могут быть подозрительные домены, IP, встроенные полезные нагрузки.
• Посмотрите на «Community» вкладку: иногда пользователи оставляют комментарии с контекстом (фальшивый установщик, бандл с адварем, легаitimate tool, используемый злоумышленниками — LOLBin).

Шаг 3. Проверка цифровой подписи (Authenticode)

Легальные исполняемые файлы Windows чаще всего подписаны сертификатом разработчика (EV или стандартный Code Signing). Подпись подтверждает: файл не менялся после подписания, и известен издатель (Subject).

Как проверить в проводнике:

1. Правый клик на файле → Свойства → вкладка «Цифровые подписи».
2. Выберите подпись → «Сведения» → «Просмотреть сертификат».
3. Проверьте: «Кому выдан» (Subject) — соответствует ли имя разработчику? «Кем выдан» (Issuer) — известный CA (DigiCert, Sectigo, GlobalSign и т.д.)? Срок действия — не истёк? Назначение — Code Signing?

В PowerShell (подробнее):

1. Get-AuthenticodeSignature «C:\путь\к\файлу.exe» | Format-List *
2. Поле Status должен быть Valid. SignerCertificate.Subject — имя компании. TimeStamperCertificate — наличие временной метки (подпись остаётся валидной после истечения сертификата).

Что искать:

• EV-сертификат (Extended Validation) — жёсткая верификация организации, сложнее получить злоумышленнику. В свойствах сертификата часто видно «Extended Validation» или OID политики 2.23.140.1.1.
• Подпись с меткой времени (RFC 3161) — файл остаётся доверенным после истечения срока сертификата.
• Отсутствие подписи — не признак вируса (многие open-source утилиты не подписаны), но повод для повышенного внимания.
• Подпись на «левое» имя (например, «Microsoft Corporation» у неизвестной утилиты) — признак подделки или кражи сертификата.

Ограничение: Подпись гарантирует целостность и авторство, но не безопасность логики кода. Подписанный вредонос бывает (украденные сертификаты, компрометированные билд-серверы, легальные инструменты администрирования — PsExec, Mimikatz, RDPWrap — используемые в атаках).

Шаг 4. Статический анализ: строки, импорт, структура PE

Без запуска файла можно извлечь много индикаторов: подозрительные строки (IP, URL, пути, base64-блобы, команды PowerShell), импортируемые API (CreateRemoteThread, VirtualAllocEx, WriteProcessMemory — признаки инъекций; URLDownloadToFile, WinHttpOpen — загрузчики), секции с высокой энтропией (упаковщики, шифрование).

Инструменты (портативные, не требуют установки):

• Strings (Sysinternals) — strings.exe -nobanner файл.exe | findstr /i «http powershell cmd.exe base64». Ключ -n задаёт мин. длину строки.
• PE-bear / CFF Explorer / LordPE — GUI для разбора PE-заголовков, секций, импорт/экспорт таблиц, ресурсов, сертификатов. Позволяет увидеть аномалии: нестандартные имена секций (.upx, .themida, .vmp), несоответствие Entry Point, отсутствие манифеста, подозрительные ресурсы (встроенные EXE/DLL/скрипты).
• Detect It Easy (DIE) — определяет упаковщик, компилятор, язык, библиотеки. Если файл упакован UPX, Themida, VMProtect, Enigma — статический анализ затруднён, это повод для динамической проверки.
• PEStudio — комплексный статический сканер: показывает VirusTotal хеш, импорт/экспорт, строки, энтропию секций, подписи, MITRE ATT&CK теги по импортам. Есть портативная версия.
• YARA + правила (например, YARA-Rules репозиторий) — если умеете писать/подбирать правила, можно сканировать файл на наличие известных паттернов малвари.

На что обратить внимание (красные флаги):

• Импорт LoadLibrary + GetProcAddress без явных импортов — динамическая загрузка API для обхода статического анализа.
• Секции с энтропией > 7.0 — сильный признак упаковки/шифрования.
• Строки с base64-длинными блоками (>100 символов) — часто зашифрованная конфигурация или вложенный полезный код.
• Встроенные ресурсы типа RT_RCDATA с исполняемым кодом (MZ-заголовок внутри).
• Отсутствие манифеста (requestedExecutionLevel) — может указывать на старый код или попытку запуска с высокими привилегиями через UAC bypass.
• Несоответствие архитектуры: 32-битный файл с 64-битными импортами или наоборот.

Шаг 5. Динамический анализ в изолированной среде (песочница)

Запуск файла под наблюдением — единственный способ увидеть, что он *на самом деле делает*: какие файлы создаёт/меняет, ключи реестра, сетевые соединения, процессы, инъекции, шифрование диска, ключевое логирование.

Инструмент / среда	Тип	Сложность	Что показывает	Ограничения
Windows Sandbox	Встроенная ОС	Низкая	Базовое поведение, сетевая активность (через Wireshark на хосте), изменения ФС/реестра (через ProcMon)	Нет GPU, нет сохранения состояния, некоторые малвари детектят песочницу
Виртуальная машина + снапшот	Полная ОС	Средняя	Полное поведение, можно ставить любые инструменты мониторинга	Требует ресурсов, настройки сети, времени на развёртывание
Process Monitor (ProcMon)	Логгер API	Средняя	Все вызовы ФС, реестра, процесса, сети в реальном времени с фильтрами	Огромные логи, нужен навык фильтрации, не видит внутри зашифрованного трафика
Process Hacker / System Informer	Инспектор процессов	Низкая	Модули, потоки, дескрипторы, память, сетевые соединения процесса	Только моментальный снимок/короткая история
CAPE / Cuckoo Sandbox (самохостинг)	Автоматизированная песочница	Высокая	Полный отчёт: MITRE ATT&CK, дамп памяти, PCAP, YARA, скриншоты	Сложное развёртывание, поддержка, анти-эvasion малваря
Any.Run / Hybrid Analysis (облачные)	Интерактивная песочница	Низкая	Видео выполнения, MITRE, IOC, можно взаимодействовать	Публичная загрузка файла, лимиты бесплатного тарифа

Минимальный набор для ручной проверки в VM/Sandbox:

1. Сделайте снапшот чистой системы.
2. Запустите Process Monitor (ProcMon) с фильтром: Process Name is файл.exe + Operation begins with (CreateFile, RegSetValue, WriteFile, TCP Connect). Включите «Enable Boot Logging» если нужно поймать автозапуск.
3. Запустите Wireshark на хосте (пробросьте трафик VM через хост) или внутри VM — для захвата DNS, HTTP, TLS SNI, C2 beaconing.
4. Запустите подозрительный файл. Наблюдайте 2–5 минут (многие малвари имеют задержки сна/проверки окружения).
5. Остановите ProcMon, сохраните лог (PML → CSV для анализа). Проверьте Wireshark на подозрительные домены/IP.
6. Посмотрите в Process Hacker: есть ли инъекции в другие процессы (нестандартные модули, потоки в чужом пространстве).
7. Верните снапшот VM.

Анти-песоничные трюки малвари: проверка количества ядер, объёма RAM, наличия мыши/клавиатуры, MAC-адресов виртуальных адаптеров, процессов инструментов анализа (procmon, wireshark, vboxservice), времени работы системы (uptime), недавних файлов. Если файл «ведёт себя спокойно» — не значит, что он чист. Попробуйте пошевелить мышью, подождать, запустить не из рабочего стола, а из консоли.

Шаг 6. Проверка репутации файла и индикаторов компрометации (IOC)

Если у вас есть хеш (SHA256), домены, IP, email из строк или динамического анализа — проверьте их в базах угроз:

• VirusTotal / Hybrid Analysis / MetaDefender — по хешу, IP, домену.
• AbuseIPDB, AlienVault OTX, URLhaus, ThreatFox — репутация IP/доменов/URL.
• MISP / OpenCTI (если есть доступ) — корпоративные платформы threat intelligence.
• MITRE ATT&CK Navigator — сопоставьте наблюдаемое поведение с техниками (T1055 Process Injection, T1059 Command and Scripting Interpreter, T1566 Phishing и т.д.).

Даже если файл новый, его инфраструктура (C2, дропперы) может быть известна. Совпадение IOC — сильный сигнал к изоляции.

Сценарии: как действовать в зависимости от контекста

Не каждый файл требует полного цикла. Выбирайте глубину проверки по риску:

• Популярный open-source инструмент с GitHub Releases, подпись есть, хеш совпадает, 0/70 на VT → хеш + подпись + быстрый VT достаточно. Риск минимален.
• Установник драйвера/утилиты с малоизвестного сайта, нет подписи, VT 3/70 (генераческие детеки) → + статический анализ (PEStudio, строки) + запуск в песочнице 5 минут.
• Файл из письма/мессенджера, неожиданный, «invoice.exe», «scan_copy.exe» → полный цикл: VT → хеш → строки → песочница → IOC. Вероятность малвари высока.
• Кряк/кейген/патч для ПО → почти всегда детектируются как HackTool/Riskware. Реальная полезная нагрузка часто скрыта. Проверяйте только в изолированной VM, готовой к уничтожению. Лучше — не запускать вообще.
• Корпоративный внутренний инструмент, собранный CI/CD → проверка подписи, хеша артефакта, SBOM (Software Bill of Materials), политики репозитория. Внешние сканеры не нужны, если доверяете пайплайну.

Типичные ошибки при проверке

• Верю в один «зелёный» антивирус на VT. Разные движки имеют разные базы и эвристику. 0/70 не значит «чисто». Смотрите на поведение и IOC.
• Проверяю на основной рабочей машине без снапшота. Один клик по вредоносному установщике с UAC bypass — и система скомпрометирована.
• Игнорирую отсутствие подписи у коммерческого ПО. Легальные вендоры почти всегда подписывают. Отсутствие — повод уточнить источник.
• Не смотрю на строки и импорт. Многие загрузчики и дропперы видны статически за 30 секунд.
• Загружаю конфиденциальный файл на публичный VT. Данные утекают исследователям и, возможно, атакующим. Используйте локальные инструменты.
• Доверяю имени файла или иконке. setup.exe с иконкой Adobe может быть чем угодно. Проверяйте содержимое.
• Запускаю в песочнице с интернетом. Малварь скачивает вторую стадию, экспфильтрует данные, получает команды. Отключайте сеть для статического/начального динамического анализа.

Чек-лист: быстрая верификация за 2 минуты (если времени нет на глубокий анализ)

1. Скачайте файл только с официального сайта / проверенного зеркала (проверьте TLS-сертификат сайта, домен).
2. Посчитайте SHA256 (PowerShell: Get-FileHash -Algorithm SHA256 файл.exe). Сравните с эталоном на сайте разработчика / в релизах GitHub / в Chocolatey/Scoop.
3. Проверьте цифровую подпись (Проводник → Свойства → Цифровые подписи). Имя издателя совпадает? Сертификат валиден? Есть timestamp?
4. Загрузите хеш на VirusTotal (не сам файл, если конфиденциальен — используйте API или локальный поиск по хешу). Оцените детекты и вкладку «Behavior / Relations».
5. Если подписи нет, детекты есть, или файл неожиданный — запустите в Windows Sandbox / VM с отключённым интернетом. Наблюдайте 2–3 минуты через ProcMon / Process Hacker.
6. Если подозрительная активность (сетевые соединения, запись в автозапуск, инъекции, шифрование файлов) — не запускайте на основной системе. Отправьте на глубокий анализ спецам / в корпоративный SOC.

Когда обращаться к специалистам

• Файл прошёл все проверки, но вы обнаружили аномалии в поведении системы после запуска (новые процессы, сетевая активность, изменённые файлы, сработавшие правила EDR).
• Инцидент в корпоративной среде: файл прошёл через почтовый шлюз, запущен сотрудником, есть признаки компрометации (алерты SIEM, EDR, сетевые IOC).
• Нужно восстановить цепочку атаки, извлечь конфигурацию малвари, атрибутировать группировку — требуется реверс-инжиниринг (IDA Pro, Ghidra, x64dbg), дамп памяти, анализ зашифрованного трафика.
• Подозрение на целевую атаку (APT), supply chain compromise, использование нулевых уязвимостей.

Практический итог: главный принцип

Проверка EXE-файла — это не бинарное решение «вирус/не вирус», а оценка риска слоёв защиты. Хеш подтверждает целостность загрузки. Подпись — авторство и неизменность после сборки. Многосканер — известные сигнатуры. Статический анализ — подозрительные конструкции без запуска. Динамический анализ в изоляции — реальное поведение. Каждый слой закрывает слепые зоны предыдущего.

Для большинства бытовых сценариев достаточно первых трёх шагов (хеш, подпись, VirusTotal по хешу) + песочница на 2 минуты при малейшем сомнении. Главное — не проверять на боевой системе без отката. Создайте привычку: «сначала песочница, потом основная ОС». Это занимает секунды с Windows Sandbox, а экономит часы восстановления после инцидента.

Материал носит информационный характер и не заменяет профессиональной экспертизы по информационной безопасности. При обнаружении признаков компрометации корпоративных систем, кражи данных или целевой атаки обратитесь к специалистам SOC / DFIR. Использование описанных инструментов для анализа чужого ПО без авторизации может нарушать условия лицензий и законодательство.

FAQ: частые вопросы

Можно ли доверять файлу, если на VirusTotal 0/70 детектов?

Нет. Отсутствие детектов означает только, что этот конкретный образец ещё не попал в сигнатурные базы 70 движков. Новые малвари (zero-day), полиморфные образцы, целевые атаки часто имеют 0/70. Обязательно смотрите вкладки Behavior, Relations, Community и проверяйте хеш в других базах.

Нужно ли проверять файлы из Microsoft Store / winget / Chocolatey?

Риск там ниже: пакеты проходят модерацию, подписаны репозиторием, хеши зафиксированы в манифестах. Но ошибки случаются (компрометация аккаунта мейнтейнера, вредоносный PR в open-source зависимость). Хеш и подпись всё равно стоит сверять, особенно для критических систем.

Что делать, если файл упакован UPX / Themida / VMProtect и не анализируется статически?

Упаковка — не признак вируса (многие легальные программы защищают IP так), но препятствует статическому анализу. Варианты: распаковать вручную (UPX: upx -d файл.exe), запустить в песочнице и снять дамп памяти (Process Hacker → Create Dump), использовать динамический анализ. Если файл легальный — у вендора обычно есть неупакованная версия или символы.

Можно ли проверить EXE на телефоне (Android/iOS)?

EXE — формат Windows. На телефоне он не запустится. Можно только загрузить хеш на VT через браузер или приложение VirusTotal Mobile. Полноценный статический/динамический анализ требует Windows-среду (VM, Sandbox, удалённый рабочий стол).

Как проверить файл, если он больше лимита VirusTotal (650 МБ)?

Используйте локальные сканеры (ClamAV, Kaspersky Virus Removal Tool, ESET SysRescue) или разбейте анализ: проверьте хеш в VT (хеш считается мгновенно для любого размера), сделайте статический анализ PEStudio / DIE, запустите в VM с ProcMon. Для больших установщиков часто достаточно проверить встроенные MSI/CAB/MSIX ресурсы отдельно.