Как проверить .ps1-скрипт на наличие деструктивных команд перед запуском

Скачали скрипт из интернета, получили от коллеги или нашли в старом проекте — и вот он лежит на рабочем столе, выглядит безобидно. Но запускать вслепую — плохая идея. Одна строчка вроде Remove-Item -Recurse -Force C:\ может стоить вам рабочей станции. Давайте разберёмся, как быстро и вдумво проанализировать PowerShell-скрипт перед тем, как нажать F5.

Почему это вообще важно

PowerShell — это не просто «командная строка для винды». Это полноценная среда с доступом к .NET, WMI, COM-объектам, реестру, файловой системе и сети. Скрипт может удалить файлы, поменять настройки безопасности, отключить службы, отправить данные наружу или загрузить что-то по сети. При этом выглядит он как обычный текстовый файл — никаких предупреждений система не показывает.

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

Шаг 1. Прочитайте скрипт целиком (хотя бы бегло)

Звучит очевидно, но большинство людей доверяют первым строкам и названию файла. Откройте .ps1 в любом текстовом редакторе — подойдёт даже Блокнот, но удобнее VS Code с расширением PowerShell или Notepad++. Пролистайте весь файл от начала до конца.

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

Шаг 2. Вытащите все подозрительные команды

PowerShell богат на команды, которые могут навредить. Вот список того, что нужно искать в первую очередь:

• Удаление: Remove-Item, Del, rm, rmdir, rd, Clear-RecycleBin
• Изменение файлов: Set-Content, Out-File, Write-Host (если перезаписывает важные файлы)
• Работа с реестром: Set-ItemProperty, New-Item, Remove-Item в разделах HKLM или HKCU
• Службы и процессы: Stop-Service, Stop-Process, Set-Service, sc.exe
• Сеть: Invoke-WebRequest, Invoke-RestMethod, Start-BitsTransfer, Net.WebClient
• Выполнение кода: Invoke-Expression, iex, Invoke-Command, Start-Process
• Изменение политик: Set-ExecutionPolicy, Set-StrictMode
• Шифрование и кодирование: ConvertTo-SecureString, [Convert]::FromBase64String, работа с сертификатами

В VS Code достаточно нажать Ctrl+F и по очереди вставить каждый из этих терминов. Если скрипт использует псевдонимы (например, rm вместо Remove-Item), ищите и их тоже.

Шаг 3. Проверьте сетевые вызовы

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

• URL-адреса в кавычках — особенно на неизвестных доменах
• Команды Invoke-WebRequest и iwr
• Конструкции вида (New-Object Net.WebClient).DownloadString("...")
• Вызовы DownloadFile, DownloadData
• Использование Start-Process с путём к временной папке

Нашли подозрительный URL? Не открывайте его в браузере. Вместо этого проверьте домен через VirusTotal или просто поищите его в поисковике в кавычках. Если домен выглядит как набор случайных символов — перед вами почти наверняка вредоносный скрипт.

Шаг 4. Обратите внимание на обфускацию

Когда автор хочет скрыть содержимое скрипта, он прибегает к трюкам. Вот признаки того, что скрипт пытаются запутать:

• Длинные строки с Base64 — например, [Convert]::FromBase64String("SGFIYXJkIHRvIHJlYWQ=")
• Использование переменных с бессмысленными именами: a = "I";b = "nvoke-Expres"; c = "a$b"
• Множественные обратные кавычки внутри строк — они экранируют символы и сбивают с толку при чтении
• Вызовы через переменные: & $someVariable, когда непонятно, что в переменной
• Скрипт упакован в одну строку с разделителем ;
• Использование Invoke-Expression с динамически собранной строкой

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

Шаг 5. Используйте встроенные средства анализа

В PowerShell есть инструмент, который часто недооценивают — Script Analyzer. Он не сканирует на вирусы, но находит подозрительные паттерны и нарушения лучших практик.

Установите модуль, если его ещё нет:

Install-Module -Name PSScriptAnalyzer -Scope CurrentUser -Force

Запустите анализ:

Invoke-ScriptAnalyzer -Path C:\path\to\your\script.ps1

Он покажет предупреждения вроде «использование псевдонимов», «вызов с пустым параметром», «потенциально небезопасная конструкция». Это не прямой детектор вредоносного кода, но помогает найти места, где стоит присмотреться внимательнее.

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

Get-ExecutionPolicy

Шаг 6. Запустите в изолированной среде

Даже после всех проверок не запускайте незнакомый скрипт на рабочей машине. Вот варианты безопасного тестирования:

Идеальный сценарий: запускаете скрипт в виртуалке со снапшотом, смотрите что произошло, откатываетесь. Если после выполнения пропали файлы, появились новые процессы или изменились настройки сети — скрипт деструктивный.

Шаг 7. Отследите, что именно делает скрипт

PowerShell умеет вести детальный лог всех действий. Включите трассировку перед запуском:

Set-PSDebug -Trace 2

Или используйте логирование через Transcript:

Start-Transcript -Path C:\logs\script_run.txt
.\your_script.ps1
Stop-Transcript

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

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

Частые ошибки при проверке

Ошибка 1. Проверять только начало скрипта. Деструктивные команды часто прячут в конце или внутри условий, которые срабатывают только при определённых условиях.

Ошибка 2. Игнорировать переменные. Если скрипт содержит url = "http://..." и дальше использует url — нужно отследить, чему равна переменная, а не просто пропустить строку.

Ошибка 3. Не проверять импортируемые модули. Скрипт может загружать модуль, а тот уже делает всю грязную работу. Смотрите строки Import-Module и #Requires -Module.

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

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

Что делать в зависимости от вашей ситуации

Скрипт от известного разработчика или из доверенного репозитория: бегло просмотрите код, проверьте сетевые вызовы, запустите в виртуалке. Обычно этого достаточно.

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

Скрипт, который вы не можете понять: не запускайте. Если код настолько запутан, что вы не можете объяснить каждую строку — это не ваш скрипт, и доверять ему нельзя.

Скрипт, который должен работать на продакшен-сервере: помимо проверки на деструктивные команды, прогоньте через тестовой стенд, идентичный боевому. Сравните состояние системы до и после выполнения.

Быстрый чек-лист перед запуском

1. Открыл скрипт целиком в редакторе
2. Проверил поиском все команды из списка опасных
3. Нашёл и проверил все URL и сетевые вызовы
4. Убедился, что нет обфускации и динамического выполнения кода
5. Проверил импортируемые модули и зависимости
6. Запустил Script Analyzer — нет критических предупреждений
7. Запустил в изолированной среде с минимальными правами
8. Просмотрел лог (Transcript) после выполнения
9. Убедился, что состояние системы не изменилось неожиданно

Итог

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

Начните с малого: заведите привычку открывать незнакомый скрипт в редакторе и искать команды из списка выше. Через пару раз это станет автоматическим — и вы перестанете рисковать там, где можно проверить.