BAT, CMD, VBS-скрипты: как проверить перед запуском

Скриптовые файлы — .bat, .cmd, .vbs, .ps1, а также смежные с ними .js, .wsf и .hta — объединяет одно: это не скомпилированная программа, а текст с командами, который операционная система выполняет построчно через свой интерпретатор. Именно поэтому их так часто используют для доставки вредоносного кода: написать и изменить такой скрипт проще, чем собрать полноценный исполняемый файл, а часть пользователей по-прежнему считает «просто текстовый файл» безопаснее .exe.

Почему расширению .bat/.vbs/.ps1 нельзя доверять на вид

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

Разница в интерпретаторе важна практически: .bat-файл ограничен возможностями командной строки, а .ps1 через PowerShell может сделать с системой почти всё — от скачивания файлов до загрузки кода прямо в память процесса. Поэтому проверять скрипт перед запуском нужно именно по его реальному расширению, а не по тому, как он выглядит на иконке.

Как малварь прячется внутри скрипта: разбор реального случая

Чтобы понимать, что именно искать при проверке, полезно разобрать один зафиксированный случай — опубликованный на Habr технический разбор реального VBS-скрипта с многослойной обфускацией. Это разбор одного конкретного образца, а не статистика по всем вредоносным скриптам, но он хорошо показывает логику, которую используют и другие похожие угрозы.

Скрипт был устроен так, что сам читал собственное содержимое через WScript.ScriptFullName — то есть открывал себя как обычный файл и извлекал из своего же текста зашифрованные данные. Дальше эти данные проходили цепочку расшифровки: сначала простое XOR, затем AES в режиме CBC — комбинация, которая усложняет статический анализ, потому что реальная полезная нагрузка не видна в самом файле до момента выполнения.

После расшифровки скрипт не записывал итоговый код на диск, а загружал .NET-сборку прямо в память процесса через [Reflection.Assembly]::Load — это значит, что на жёстком диске не оставалось отдельного «вирусного файла», который можно было бы просто найти и удалить. Запуск дальнейшего кода маскировался под легитимный процесс — через MSBuild.exe, стандартный инструмент сборки .NET, который редко попадает под подозрение у пользователя и части защитных решений.

Отдельно в разборе отмечены типичные флаги PowerShell, которые использовались на следующих этапах: -WindowStyle Hidden (запуск без видимого окна) и Set-ExecutionPolicy Bypass (временное снятие ограничения на запуск неподписанных скриптов). Скрипт также проверял LanguageMode PowerShell — это способ определить, не запущен ли он в ограниченной среде вроде песочницы или корпоративной политики безопасности, и изменить поведение, если обнаружено наблюдение.

На что это похоже внешне

Снаружи такой файл выглядит как обычный «безопасный» текстовый документ: несколько строк комментариев вида 'DATA:, за которыми следует длинный бессмысленный на вид набор символов — тот самый зашифрованный и закодированный в Base64 полезный код. Человек, открывший файл просто посмотреть, скорее всего решит, что это «какой-то технический мусор», и закроет его, не распознав угрозу — именно на эту реакцию и рассчитана обфускация.

Что искать, если открыть скрипт в Блокноте перед запуском

Прежде чем запускать незнакомый .bat, .vbs или .ps1-файл, его стоит сначала прочитать — но не двойным кликом (это сразу его выполнит), а через контекстное меню «Изменить» или явное открытие в Блокноте.

1. Откройте файл правой кнопкой мыши → «Изменить» (или «Открыть с помощью» → Блокнот). Ни в коем случае не двойной клик — для .bat/.cmd/.vbs/.js/.wsf/.hta это сразу запустит код.
2. Прочитайте текст целиком, а не только начало. Вредоносная часть часто спрятана в конце файла или после большого блока комментариев-«шума».
3. Поищите длинные бессмысленные строки символов. Это обычно Base64-кодированная полезная нагрузка — легитимные скрипты редко содержат такие блоки без пояснения.
4. Поищите флаги -enc или -EncodedCommand. Это прямой признак того, что PowerShell должен выполнить закодированную, то есть скрытую от беглого просмотра команду.
5. Поищите WindowStyle Hidden и Set-ExecutionPolicy Bypass. Легитимным административным скриптам обычно незачем прятать своё окно и обходить политику выполнения.
6. Поищите обращения к незнакомым IP-адресам или доменам. Строки с http:///https:// и явными числовыми IP в теле скрипта — повод насторожиться, особенно если скрипт пришёл не от разработчика ПО.
7. Обратите внимание на нестандартные маркеры-разделители. Комментарии вроде 'DATA: или похожие самодельные метки часто используются именно для того, чтобы скрипт мог найти и расшифровать свою же полезную нагрузку — обычным скриптам такие маркеры не нужны.

Как проверить скрипт перед запуском — пошагово

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

1. Посчитайте хэш файла. В PowerShell выполните Get-FileHash <путь к файлу> -Algorithm SHA256 — команда вернёт контрольную сумму, по которой можно однозначно идентифицировать конкретный файл, независимо от его названия. Подробнее о том, как и зачем это делать, — в статье как проверить контрольную сумму файла. Документация команды — у Microsoft Learn.
2. Проверьте хэш (или сам файл) на VirusTotal. Если файл уже встречался другим пользователям сервиса, достаточно вставить посчитанный хэш в поиск — результат появится мгновенно без загрузки содержимого. Если хэш не найден, можно загрузить сам скрипт на VirusTotal — сервис прогонит его через десятки антивирусных движков. Общий порядок такой проверки для любых файлов, не только скриптов, разобран в статье как проверить файл на вирусы онлайн.
3. Посмотрите цифровую подпись файла. Команда Get-AuthenticodeSignature <путь к файлу> в PowerShell покажет, подписан ли скрипт и кем именно (документация — у Microsoft Learn). Подпись от известного и доверенного издателя — хороший сигнал; статус «не подписан» сам по себе не доказывает вредоносность (многие безобидные административные скрипты тоже не подписаны), но в сочетании с другими признаками повышает осторожность.
4. При малейших сомнениях — прогоните скрипт в изолированной среде. Встроенный в Windows 10/11 Pro Windows Sandbox или онлайн-песочницы вроде ANY.RUN и Hybrid Analysis запускают файл в полностью изолированной системе и показывают его реальное поведение — какие процессы он создаёт, куда обращается по сети, что меняет в системе. Поведенческий анализ в песочнице ловит угрозы, которые пропускает статическое сканирование: обфусцированный код расшифровывается и проявляет себя только в момент выполнения.

Если скрипт пришёл от «надёжного» источника — как запустить без риска

Даже когда скрипт прислал коллега, скачан с сайта разработчика ПО или идёт в комплекте с легальной программой, стоит соблюдать несколько правил запуска — они не требуют отдельной проверки, но снижают ущерб, если источник всё же оказался скомпрометирован.

• Запускайте скрипт под обычной учётной записью, а не под администратором — если потребуются повышенные права, Windows отдельно спросит об этом через UAC.
• Не отключайте Windows Defender и SmartScreen «чтобы не мешали» — это штатные фильтры первого уровня, и временное отключение ради одного запуска может остаться без контроля надолго.
• Не переводите ExecutionPolicy PowerShell в Unrestricted глобально. Если конкретный доверенный скрипт требует обхода политики, делайте это разово для одного запуска, а не меняйте политику для системы целиком.

Уже запустили подозрительный скрипт — что делать дальше

Если скрипт уже был запущен и после этого появились сомнения в его безопасности, действовать нужно быстро и по порядку.

1. Отключите устройство от сети. Выключите Wi-Fi или выдерните кабель — это остановит возможную передачу данных наружу и загрузку дополнительных вредоносных компонентов.
2. Проверьте автозагрузку. Откройте Планировщик заданий (Task Scheduler) и посмотрите, не появились ли новые незнакомые задачи; проверьте ветки реестра Run и RunOnce — туда часто добавляют записи для повторного запуска при каждой загрузке системы.
3. Запустите offline-сканирование Microsoft Defender. Этот режим проверяет систему до полной загрузки Windows, что помогает обнаружить компоненты, которые прячутся от обычного сканирования в рабочей сессии.
4. Если файлы на диске оказались зашифрованы — это уже не обычное заражение, а программа-вымогатель, и здесь другой алгоритм действий. Не платите выкуп сразу — иногда файлы можно восстановить другими способами, подробный разбор — в статье как восстановить файлы после шифровальщика без выкупа.

Чек-лист перед запуском любого .bat/.vbs/.ps1-файла

Частые вопросы

Читайте также

• Карта опасных расширений: 60 форматов, которые нельзя открывать двойным кликом →
• Опасные расширения файлов: что нельзя открывать без проверки →
• Как проверить файл на вирусы онлайн без установки антивируса →
• Как проверить контрольную сумму файла и зачем это нужно →
• Двойное расширение файла: как распознать подмену →
• Как восстановить файлы после шифровальщика без выкупа →