В мире информационной безопасности, где каждый день — это новая битва, а противник постоянно эволюционирует, есть инструменты, которые из верных помощников превращаются в оружие в руках злоумышленников. Один из таких «Троянских коней» последних лет, по моей личной оценке и по наблюдениям за нашими российскими реалиями к 2025 году, это, несомненно, PowerShell. Когда-то он был мечтой любого админа — мощный, гибкий, позволяющий автоматизировать всё, что шевелится в Windows-инфраструктуре. А теперь? Теперь это излюбленный инструмент для «жизни на земле» (living off the land) для тех, кто хочет нагадить незаметно и эффективно. И поверьте, я на своей шкуре не раз ощущал, как эта гибкость оборачивается головной болью.
PowerShell: от друга к врагу
Почему именно PowerShell? Всё просто: он есть везде, в каждой Windows-системе, начиная с Windows 7 и Server 2008 R2. Он не требует установки, не вызывает подозрений у большинства антивирусов на старте, потому что это системный компонент. Для атакующего это как швейцарский нож: можно загрузить вредоносный код прямо в память, не касаясь диска, можно управлять системой удаленно, можно обойти многие традиционные средства защиты. Помню, как-то раз, году эдак в 2022-м, на одном из объектов, где я консультировал, мы наткнулись на фишинговую кампанию, которая доставляла не привычные .exe или .doc с макросами, а хитроумный .lnk-файл. При запуске он через командную строку дергал PowerShell, который уже качал и запускал основной пейлоад. Ни один антивирус на рабочих станциях тогда не пикнул, потому что PowerShell.exe — это же «добро».
За кулисами атаки: как это работает
Сценариев использования PowerShell для вредоносных действий — море. Но общая канва часто одна и та же:
- Начальный доступ: Это может быть что угодно: от банального RDP-брутфорса, когда атакующий заходит на сервер и руками запускает скрипт, до более изощренных атак через уязвимости в веб-приложениях, где PowerShell вызывается через веб-шелл. В моей практике был кейс, когда через дырявый плагин WordPress, стоящий на Windows-сервере (да, бывает и такое), хакеры смогли загрузить небольшой скрипт, который затем использовал
Invoke-WebRequestдля скачивания второго этапа атаки. - Маскировка и обфускация: Это отдельная песня, и тут настоящий админ начинает чувствовать себя дешифровщиком. Злоумышленники используют всё: Base64-кодирование, XOR-шифрование, конкатенацию строк, вызовы через
Invoke-Expression(короткоIEX— это вообще любимчик у них, потому что позволяет выполнить что угодно из строки), использование обратных кавычек для разбиения команд. Представьте себе строку типаI`E`X (New-Object IO.StreamReader((New-Object IO.Compression.GzipStream((New-Object IO.MemoryStream(,[System.Convert]::FromBase64String('H4sIAAAAAAAA...')), [IO.Compression.CompressionMode]::Decompress)))).ReadToEnd(). И это еще относительно простой вариант. Мой лайфхак: если видите в логахIEXилиInvoke-Expression, особенно в комбинации с Base64, это красный флаг размером с автобус. Берем эту Base64-строку, декодируем, и почти всегда видим там нечто интересное. Недавно я ловил майнер, который вообще использовал WMI для запуска PowerShell-скриптов, а сам скрипт был разбит на куски и хранился в разных ветках реестра, собираясь в кучу уже в памяти. Это такой уровень маскировки, что без глубокого анализа логов Event ID 4104 (подробное логирование скриптов PowerShell) ты его и не заметишь. - Закрепление в системе: Просто выполнить код мало, нужно остаться. Для этого PowerShell опять-таки незаменим:
- Планировщик задач (Scheduled Tasks): Создание задачи, которая запускается при входе пользователя, при старте системы или по расписанию. Часто используют имена, похожие на системные, типа «Microsoft Update Health Check».
- Реестр (Registry Run keys): Добавление записи в
HKCUSoftwareMicrosoftWindowsCurrentVersionRunилиHKLM.... - WMI Event Subscriptions: Это вообще высший пилотаж для невидимого закрепления. Вредоносный скрипт может создать WMI-событие, которое запускается при определенном триггере (например, при запуске процесса, при изменении файла) и вызывает PowerShell-скрипт. Это сложно обнаружить без специализированных инструментов, так как записи о них хранятся в репозитории WMI, а не в файлах.
AMSI и обходные пути: игра в кошки-мышки
Microsoft не сидит сложа руки, и одним из ответов на засилье PowerShell-мальвари стал AMSI — Anti-Malware Scan Interface. Это такая штука, которая позволяет антивирусу «заглянуть» внутрь скрипта PowerShell до его выполнения, даже если он обфусцирован. По сути, AMSI предоставляет антивирусу декодированный код. Звучит круто, правда? Но, как всегда, есть «но». Хакеры тоже не дураки и постоянно ищут способы обойти AMSI. Самый известный и до сих пор работающий обход — это манипуляции с памятью PowerShell-процесса, чтобы «отключить» или «испортить» AMSI до того, как он успеет просканировать вредоносный код. Это достигается через рефлексию .NET, например, путем вызова методов из класса System.Management.Automation.AmsiUtils или напрямую изменяя байты в памяти. Я лично видел, как в 2024 году, на одном из наших клиентов, прилетела атака, которая начиналась с [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiSession', 'NonPublic,Static').SetValue($null, $null). Это классический обход, который на старых версиях Windows (особенно на Server 2012 R2, которых у нас еще полно) работает как часы. На более новых версиях Windows 10/11 и Server 2019/2022 Microsoft постоянно латает эти дыры, но это вечная гонка вооружений.
Типичные сценарии в наших реалиях
В наших российских реалиях, особенно в компаниях, где IT-инфраструктура формировалась десятилетиями, PowerShell-атаки находят благодатную почву. Чаще всего я сталкиваюсь со следующими типами:
- Рансомварь (Ransomware): Это, наверное, самая болезненная история. PowerShell используется для первоначального доступа, скачивания шифровальщика (который сам может быть написан на PowerShell или быть обычным .exe), его запуска и удаления следов. Однажды, на одном из предприятий среднего бизнеса (нефтянка, представьте!), мы получили шифровальщика, который использовал PowerShell для сканирования сетевых ресурсов, определения доступных шары и запуска шифрования. Самое обидное было то, что он добрался до бэкап-сервера, который по недосмотру был в одном сегменте с остальной сетью. Восстановление заняло несколько дней и стоило компании миллионов.
- Криптомайнеры: Менее заметные, но не менее вредные. Они тихо сидят, жрут ресурсы процессора и видеокарда, превращая ваши серверы и рабочие станции в фермы для добычи криптовалюты. PowerShell здесь идеален для скрытой загрузки майнера, его запуска в памяти и постоянного контроля за его работой, чтобы он не конфликтовал с другими процессами и не слишком нагружал систему, выдавая себя.
- Инфостилеры и бэкдоры: Сбор учетных данных, документов, скриншотов, установка скрытых каналов связи. PowerShell позволяет легко получить доступ к API Windows, работать с файловой системой, сетью, реестром. Все это потом отправляется на управляющий сервер.
Лайфхаки и предостережения: что делать, когда вокруг шторм
Как админ с двадцатилетним стажем, могу сказать: полностью защититься невозможно, но минимизировать риски и ущерб — вполне. Вот что я выстрадал на своей шкуре:
- Ограниченный языковой режим PowerShell
