Что вас ждёт в статье:
1. Введение: PowerShell 7 для Blue Team
1.1. PowerShell 5.1 vs 7: что нового
1.2. Security considerations: logging, execution policy
2. Event Log Analysis
2.1. Get-WinEvent: фильтрация и поиск
2.2. Security Events: 4624, 4625, 4688, 4720
2.3. Anomaly detection в логах
3. Threat Hunting
3.1. Поиск suspicious processes
3.2. Scheduled Tasks audit
3.3. Registry persistence check
4. AMSI и ScriptBlock Logging
4.1. Мониторинг AMSI bypass
4.2. ScriptBlock log analysis
4.3. PowerShell transcription
5. Sysmon Integration
5.1. Парсинг Sysmon Events
5.2. Process creation (Event 1)
5.3. Network connection (Event 3)
6. Automated Response
6.1. Host isolation скрипт
6.2. IP blocking (firewall rules)
6.3. Process termination по IOC
7. Hardening и Audit
7.1. GPO audit
7.2. ACL verification
7.3. Baseline comparison
1. Введениe: PowerShell 7 для Blue Team
Мир корпоративного IT - это мир Windows.
Как бы сильно продвинутые пользователи и трушные технари ни балдели от прозрачности и логики Linux, суровая реальность такова:
90% офисных сетей, контроллеров домена и рабочих станций в энтерпрайзе крутятся на операционках от Microsoft.
Это делает Windows главной мишенью на планете. Огромная база кода, сложная архитектура реестра и мигрирующие между версиями уязвимые элементы представляют собой огромный пласт информации, поддающийся компрометации. Если вы занимаетесь или планируете заниматься защитой инфраструктуры в Blue Team, ты попросту и нет возможности игнорировать среду, в которой происходит 9 из 10 реальных инцидентов.
Как бы сильно продвинутые пользователи и трушные технари ни балдели от прозрачности и логики Linux, суровая реальность такова:
90% офисных сетей, контроллеров домена и рабочих станций в энтерпрайзе крутятся на операционках от Microsoft.
Это делает Windows главной мишенью на планете. Огромная база кода, сложная архитектура реестра и мигрирующие между версиями уязвимые элементы представляют собой огромный пласт информации, поддающийся компрометации. Если вы занимаетесь или планируете заниматься защитой инфраструктуры в Blue Team, ты попросту и нет возможности игнорировать среду, в которой происходит 9 из 10 реальных инцидентов.
1.1. PowerShell 5.1 vs 7: что нового
Для Blue Team специалиста переход на PowerShell 7 является своего рода психологическим барьером. Кажется, зачем что-то менять, если синее окно 5.1 и так под рукой?
Но разница здесь примерно как между старым дизельным тягачом и современным электрокаром. Старый Windows PowerShell 5.1 застрял в эпохе .NET Framework и потихоньку превращается в Legacy. Современный PowerShell 7, работающий на .NET 8, - это кроссплатформенный монстр. Он одинаково хорошо чувствует себя и на Windows, и на том же Linux, что позволяет Blue Team специалисту использовать единый инструментарий для мониторинга всей инфраструктуры.
Главная техническая мощь семерки для нас кроется в скорости. Когда нужно проанализировать гигабайты логов в поисках одной подозрительной записи, разница в производительности между версиями становится вопросом жизни и смерти хоста.
Внедрение параметра -Parallel в цикл ForEach-Object стало настоящим спасением: теперь мы можем опрашивать десятки рабочих станций на наличие вредоносных артефактов одновременно, не выстраивая сложные очереди задач. По сути, седьмая версия превратила PowerShell из скриптового языка в полноценную платформу для оперативного реагирования, которая не пасует перед большим обьёмом данных.
Но разница здесь примерно как между старым дизельным тягачом и современным электрокаром. Старый Windows PowerShell 5.1 застрял в эпохе .NET Framework и потихоньку превращается в Legacy. Современный PowerShell 7, работающий на .NET 8, - это кроссплатформенный монстр. Он одинаково хорошо чувствует себя и на Windows, и на том же Linux, что позволяет Blue Team специалисту использовать единый инструментарий для мониторинга всей инфраструктуры.
Главная техническая мощь семерки для нас кроется в скорости. Когда нужно проанализировать гигабайты логов в поисках одной подозрительной записи, разница в производительности между версиями становится вопросом жизни и смерти хоста.
Внедрение параметра -Parallel в цикл ForEach-Object стало настоящим спасением: теперь мы можем опрашивать десятки рабочих станций на наличие вредоносных артефактов одновременно, не выстраивая сложные очереди задач. По сути, седьмая версия превратила PowerShell из скриптового языка в полноценную платформу для оперативного реагирования, которая не пасует перед большим обьёмом данных.
1.2. Security considerations: logging, execution policy
Когда мы говорим о защите, нужно понимать, что хакеры обожают PowerShell не меньше нашего. Это идеальный инструмент для тактики «Living off the Land» (использование штатных средств системы для атаки), потому что вызовы PowerShell выглядят для многих антивирусов как легитимная активность админа.
Поэтому первое, что должен сделать Blue Team специалист - это перестать верить в магическую силу Execution Policy. Многие новички думают, что если политика стоит в Restricted, то скрипты не запустятся. На деле же это всего лишь легкий заборчик, который злоумышленник перепрыгивает одной командой. Настоящая битва за безопасность разворачивается на уровне телеметрии. Злоумышленники постоянно используют обфускацию, т.е. превращают свой код в нечитаемую кашу из символов и Base64, чтобы обмануть сигнатурные сканеры.
Но PowerShell устроен так, что перед непосредственным исполнением он обязан расшифровать код в чистый вид. Включённое логирование блоков скриптов заставляет систему записывать этот финальный, чистый текст прямо в Event Log.
При этом сами события в Windows хранятся в структурированном виде на основе XML. Это формат, где данные записываются в виде тегов и путей, что позволяет системам и аналитикам точно парсить и фильтровать логи, а не работать с сырым текстом. Именно поэтому такие инструменты, как PowerShell или SIEM-системы могут извлекать из событий конкретные поля и эффективно находить следы атаки.
Важное уточнение!
Чтобы наши отчеты не были пустыми, недостаточно просто включить логирование скриптов. Нам нужно видеть, с какими аргументами запускаются процессы в системе. По умолчанию Windows скрывает детали командной строки в целях экономии места. Для полноценной охоты далее нам необходимо принудительно активировать аудит создания процессов и включить запись командной строки.
Как видно на скрине, мы используем утилиту auditpol для включения аудита Process Creation и правим реестр, чтобы поле CommandLine в событиях ID 4688 перестало быть пустым. Это превратит дефолтный лог в красивую улику.
Так вот добавим к этому PowerShell Transcription, который работает как видеорегистратор для консоли, записывая каждый ввод и вывод, и получим среду, в которой ни одно действие атакующего не останется незамеченным.
Для поздней практической части статьи нам будет необходим Sysmon. Если стандартные журналы говорят нам кто-то зашел в систему, то Sysmon сообщает, что этот процесс открыл сетевое соединение с подозрительным IP.
Поэтому первое, что должен сделать Blue Team специалист - это перестать верить в магическую силу Execution Policy. Многие новички думают, что если политика стоит в Restricted, то скрипты не запустятся. На деле же это всего лишь легкий заборчик, который злоумышленник перепрыгивает одной командой. Настоящая битва за безопасность разворачивается на уровне телеметрии. Злоумышленники постоянно используют обфускацию, т.е. превращают свой код в нечитаемую кашу из символов и Base64, чтобы обмануть сигнатурные сканеры.
Но PowerShell устроен так, что перед непосредственным исполнением он обязан расшифровать код в чистый вид. Включённое логирование блоков скриптов заставляет систему записывать этот финальный, чистый текст прямо в Event Log.
При этом сами события в Windows хранятся в структурированном виде на основе XML. Это формат, где данные записываются в виде тегов и путей, что позволяет системам и аналитикам точно парсить и фильтровать логи, а не работать с сырым текстом. Именно поэтому такие инструменты, как PowerShell или SIEM-системы могут извлекать из событий конкретные поля и эффективно находить следы атаки.
Важное уточнение!
Чтобы наши отчеты не были пустыми, недостаточно просто включить логирование скриптов. Нам нужно видеть, с какими аргументами запускаются процессы в системе. По умолчанию Windows скрывает детали командной строки в целях экономии места. Для полноценной охоты далее нам необходимо принудительно активировать аудит создания процессов и включить запись командной строки.
Как видно на скрине, мы используем утилиту auditpol для включения аудита Process Creation и правим реестр, чтобы поле CommandLine в событиях ID 4688 перестало быть пустым. Это превратит дефолтный лог в красивую улику.
Так вот добавим к этому PowerShell Transcription, который работает как видеорегистратор для консоли, записывая каждый ввод и вывод, и получим среду, в которой ни одно действие атакующего не останется незамеченным.
Для поздней практической части статьи нам будет необходим Sysmon. Если стандартные журналы говорят нам кто-то зашел в систему, то Sysmon сообщает, что этот процесс открыл сетевое соединение с подозрительным IP.
2. Event Log Analysis
После того как хакер наследил в системе, логи становятся единственным источником правды. Но тут появляется проблема, заключающаяся в том, что в корпоративной среде за час генерируются миллионы событий. Пытаться найти там злоумышленника вручную - всё равно что искать иголку в стоге сена, который к тому же постоянно растет. Наша задача пока в превращении этого хаоса в структурированную базу для охоты.
2.1. Get-WinEvent: фильтрация и поиск
Когда инцидент уже произошел, время начинает работать против нас.
Стандартный Event Viewer в такие моменты превращается в обузу, ведь он долго подгружает списки, вылетает на больших объемах данных и не дает возможности для нормального поиска. В Blue Team побольшинству используется Get-WinEvent. Это основной инструмент PowerShell для работы с журналами, который обращается напрямую к API службы журналов событий. Главное преимущество здесь состоит в повышенной скорости и точности.
Вместо того чтобы тянуть из системы тысячи строк и надеяться на удачу, мы применяем параметр -FilterHashtable. Это критически важный концепт. фильтрация происходит на стороне сервиса журналов, а не в консоли. Это значит, что по сети или внутри системы передается не весь мусор, а только те несколько строк, которые соответствуют критериям команды. В PowerShell 7 это работает молниеносно. Мы формируем запрос, указывая имя журнала и нужный нам ID события.
Более того, Get-WinEvent позволяет нам нырять внутрь XML-структуры события. Большинство полезных данных запрятаны глубоко в свойствах объекта. Используя PowerShell 7, мы можем на лету вытаскивать эти значения, переименовывать их для удобства и выводить в чистую таблицу. По сути, мы превращаем нечитаемую простыню текста в структурированный отчет, где каждая колонка дает ответ на важнейший вопрос: «Кто, когда и что именно сделал в системе?». Именно эта база данных в реальном времени позволяет нам переходить к детальному анализу конкретных угроз, таких как создание подозрительных процессов.
Стандартный Event Viewer в такие моменты превращается в обузу, ведь он долго подгружает списки, вылетает на больших объемах данных и не дает возможности для нормального поиска. В Blue Team побольшинству используется Get-WinEvent. Это основной инструмент PowerShell для работы с журналами, который обращается напрямую к API службы журналов событий. Главное преимущество здесь состоит в повышенной скорости и точности.
Вместо того чтобы тянуть из системы тысячи строк и надеяться на удачу, мы применяем параметр -FilterHashtable. Это критически важный концепт. фильтрация происходит на стороне сервиса журналов, а не в консоли. Это значит, что по сети или внутри системы передается не весь мусор, а только те несколько строк, которые соответствуют критериям команды. В PowerShell 7 это работает молниеносно. Мы формируем запрос, указывая имя журнала и нужный нам ID события.
Более того, Get-WinEvent позволяет нам нырять внутрь XML-структуры события. Большинство полезных данных запрятаны глубоко в свойствах объекта. Используя PowerShell 7, мы можем на лету вытаскивать эти значения, переименовывать их для удобства и выводить в чистую таблицу. По сути, мы превращаем нечитаемую простыню текста в структурированный отчет, где каждая колонка дает ответ на важнейший вопрос: «Кто, когда и что именно сделал в системе?». Именно эта база данных в реальном времени позволяет нам переходить к детальному анализу конкретных угроз, таких как создание подозрительных процессов.
2.2. Security Events: 4624, 4625, 4688, 4720
Для Blue Team специалиста журнал безопасности является основным источником улик. Но чтобы не утонуть в гигабайтах шума, мы фокусируемся на четырех критических событиях, которые в 99% случаев сопровождают любую атаку.
Первая пара событий (ID 4624 и ID 4625) отвечает за аутентификацию.
4624 сообщает об успешном входе. Здесь мы смотрим на LogonType, и если это тип сетевого входа, то хакер может двигаться латерально по сети, а если тип RDP, то он уже сидит на рабочем столе.
4625 напротив, является главным индикатором брутфорса или попыток подбора пароля поскольку фиксирует неудачные попытки аутентификации. Когда в логах за секунду пролетает сотня таких событий, это не ошибка пользователя, это активная фаза атаки, что логично.
Вторая пара событий показывает нам действия внутри системы.
ID 4720 обозначает создание аккаунта. Если создается новый пользователь, а в сообщениях от HR или IT-отдела об этом ни слова, значит, злоумышленник создает себе черный ход для закрепления.
И, наконец, самое интересное и информативное событие - ID 4688 (Создание процесса). Оно фиксирует запуск любого приложения. Как мы видим на представленном ниже скриншоте, это событие становится бесценным, если мы, конечно, заранее включили аудит командной строки.
На скриншоте зафиксирован идеальный пример того, как PowerShell 7 вытягивает из XML-структуры события только самое важное. Мы видим точное время запуска, имя процесса и CommandLine. Без предварительной настройки (о которой мы говорили в Главе 1.2) поле командной строки было бы пустым, и мы бы никогда не узнали, что именно выполнял, например, svchost.exe. Теперь же любая попытка хакера запустить обфусцированный скрипт или системную утилиту с подозрительными флагами будет видна как на ладони.
Обсудив теорию и небольшую демонстрацию, прошу к рассмотрению и возможному использованию в полях следующих скриптов:
ID 4624 (Мониторинг успешных входов)
Первая пара событий (ID 4624 и ID 4625) отвечает за аутентификацию.
4624 сообщает об успешном входе. Здесь мы смотрим на LogonType, и если это тип сетевого входа, то хакер может двигаться латерально по сети, а если тип RDP, то он уже сидит на рабочем столе.
4625 напротив, является главным индикатором брутфорса или попыток подбора пароля поскольку фиксирует неудачные попытки аутентификации. Когда в логах за секунду пролетает сотня таких событий, это не ошибка пользователя, это активная фаза атаки, что логично.
Вторая пара событий показывает нам действия внутри системы.
ID 4720 обозначает создание аккаунта. Если создается новый пользователь, а в сообщениях от HR или IT-отдела об этом ни слова, значит, злоумышленник создает себе черный ход для закрепления.
И, наконец, самое интересное и информативное событие - ID 4688 (Создание процесса). Оно фиксирует запуск любого приложения. Как мы видим на представленном ниже скриншоте, это событие становится бесценным, если мы, конечно, заранее включили аудит командной строки.
На скриншоте зафиксирован идеальный пример того, как PowerShell 7 вытягивает из XML-структуры события только самое важное. Мы видим точное время запуска, имя процесса и CommandLine. Без предварительной настройки (о которой мы говорили в Главе 1.2) поле командной строки было бы пустым, и мы бы никогда не узнали, что именно выполнял, например, svchost.exe. Теперь же любая попытка хакера запустить обфусцированный скрипт или системную утилиту с подозрительными флагами будет видна как на ладони.
Обсудив теорию и небольшую демонстрацию, прошу к рассмотрению и возможному использованию в полях следующих скриптов:
ID 4624 (Мониторинг успешных входов)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20 | select TimeCreated, @{N='User'; E={$[I].Properties[5].Value}}, @{N='Type'; E={$[/I].Properties[8].Value}}, @{N='IP'; E={$_.Properties[18].Value}} | ft -AutoSizeID 4625 (Детект брутфорса)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 50 | select TimeCreated, @{N='Target'; E={$[I].Properties[5].Value}}, @{N='Status'; E={$[/I].Properties[7].Value}}, @{N='IP'; E={$_.Properties[19].Value}} | ft -AutoSizeID 4688 (Аудит создания процессов как в демонстрации)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 10 | select TimeCreated, @{N='Proc'; E={$[I].Properties[5].Value}}, @{N='Cmd'; E={$[/I].Properties[8].Value}} | flID 4720 (Создание новых учетных записей)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4720} | select TimeCreated, @{N='ByAdmin'; E={$[I].Properties[4].Value}}, @{N='NewUser'; E={$[/I].Properties[0].Value}} | ft -AutoSizeДа, они сильно похожи, однако, каждый из них адаптирован под особенности каждого события. Windows хранит логи в структурированном XML-формате, где каждому информационному полю присвоен строгий индекс в массиве «Properties». Различия в индексах обусловлены спецификой метаданных каждого Event ID. Эту историю мы рассмотрим детально в 5ой главе.
2.3.Anomaly detection в логах
Работа с логами включает в себя в том числе поиск следов его закрепления в системе. Одной из наиболее распространенных техник закрепления является использование планировщика задач Windows. Злоумышленники создают поддельные задания, которые имитируют системные процессы или обновления популярного софта, чтобы обеспечить себе автоматический перезапуск вредоносного кода.
Для обнаружения таких угроз мы применяем метод анализа аномалий, основанный на исключении доверенного контекста. Вместо того чтобы просматривать сотни легитимных задач вручную, мы формируем динамический белый список, включающий известных издателей ПО и стандартные пути Microsoft. Всё, что не проходит через этот фильтр, автоматически классифицируется как подозрительный объект и требует немедленного анализа.
На практике задетектить описанную выше аномалию можно следующим образом:
Мы видим, как скрипт игнорирует сотни стандартных задач Windows (не без промахов, конечно) и моментально подсвечивает аномалию первой же строчкой. Имеем задачу с именем Edge_Security_Update.
При детальном рассмотрении выясняется, что она инициирует запуск powershell.exe с флагом -ExecutionPolicy Bypass в скрытом режиме. А если приглядеться ещё пристальнее, то там прямым текстом написано «Write-Host Hacked», что вкупе, согласитесь, наталкивает на определенные мысли.
Немного переписал скрипт, он сократился и стал в формате однострочника для лучшей копируемости в капризный PowerShell:
Для обнаружения таких угроз мы применяем метод анализа аномалий, основанный на исключении доверенного контекста. Вместо того чтобы просматривать сотни легитимных задач вручную, мы формируем динамический белый список, включающий известных издателей ПО и стандартные пути Microsoft. Всё, что не проходит через этот фильтр, автоматически классифицируется как подозрительный объект и требует немедленного анализа.
На практике задетектить описанную выше аномалию можно следующим образом:
Мы видим, как скрипт игнорирует сотни стандартных задач Windows (не без промахов, конечно) и моментально подсвечивает аномалию первой же строчкой. Имеем задачу с именем Edge_Security_Update.
При детальном рассмотрении выясняется, что она инициирует запуск powershell.exe с флагом -ExecutionPolicy Bypass в скрытом режиме. А если приглядеться ещё пристальнее, то там прямым текстом написано «Write-Host Hacked», что вкупе, согласитесь, наталкивает на определенные мысли.
Немного переписал скрипт, он сократился и стал в формате однострочника для лучшей копируемости в капризный PowerShell:
$W = @("Microsoft","Windows","Wpd"); $P = ($W -join "|"); Get-ScheduledTask | ? { $[I].TaskPath -notmatch $P } | % { Write-Host "[!] ОБНАРУЖЕНА СТРАННАЯ ЗАДАЧА: $($[/I].TaskName)" -FG Red; Write-Host " Действие: $($[I].Actions.Execute) $($[/I].Actions.Arguments)" -FG Yellow; Write-Host "---" }
3. Threat Hunting
Threat Hunting - это проактивная проверка гипотезы о компрометации системы.
В этой главе мы сфокусируемся на поиске следов жизнедеятельности атакующего в оперативной памяти и механизмах автозагрузки.
В этой главе мы сфокусируемся на поиске следов жизнедеятельности атакующего в оперативной памяти и механизмах автозагрузки.
3.1. Поиск suspicious processes
Просто смотреть на список запущенных процессов через Get-Process бесполезно, хакеры давно научились называть свои бинарники svchost.exe или lsass.exe. Настоящая охота начинается тогда, когда мы ищем не по именам, а по поведенческим признакам.
Одним из самых ярких признаков аномалии является запуск PowerShell с флагами скрытия окна или обхода политик. На скриншоте ниже мы опрашиваем события создания процессов и мгновенно фильтруем их по специфическим ключевым словам.
Мы используем оператор -match с регулярным выражением "Hidden|Bypass". Как видно на результате, система моментально выдала подозрительный процесс. Легитимному системному администратору крайне редко нужно запускать PowerShell в скрытом режиме с обходом всех защит. Для Blue Team это однозначный IOC (индикатор компрометации), требующий немедленной изоляции хоста.
Скрипт:
Одним из самых ярких признаков аномалии является запуск PowerShell с флагами скрытия окна или обхода политик. На скриншоте ниже мы опрашиваем события создания процессов и мгновенно фильтруем их по специфическим ключевым словам.
Мы используем оператор -match с регулярным выражением "Hidden|Bypass". Как видно на результате, система моментально выдала подозрительный процесс. Легитимному системному администратору крайне редко нужно запускать PowerShell в скрытом режиме с обходом всех защит. Для Blue Team это однозначный IOC (индикатор компрометации), требующий немедленной изоляции хоста.
Скрипт:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 10 | Where-Object { $[I].Properties[8].Value -match "Hidden|Bypass" } | Select-Object TimeCreated, @{N='Process';E={$[/I].Properties[5].Value}}, @{N='CommandLine';E={$_.Properties[8].Value}} | fl
3.2. Scheduled Tasks audit
Закрепление в системе через планировщик задач - это нестареющая классика целевых атак. Для атакующего это идеальный инструмент, ведь он позволяет выполнять код с system правами или конкретного пользователя, не требуя постоянного присутствия в сессии.
Главная проблема для Blue Team здесь заключается в объеме данных, потому что в типичной Windows-инфраструктуре работают сотни легитимных задач от обновлений браузеров до системных триггеров телеметрии. В этом шуме хакеру проще всего спрятать свой маяк для закрепления.
Как мы уже демонстрировали в разделе 2.3, эффективный аудит строится на принципе исключения доверенного контекста. Однако, помимо фильтрации по путям, аналитик должен обращать внимание на триггеры запуска. Подозрение должны вызывать задачи, срабатывающие при простое системы или стабильно обращающиеся раз в какой-то промежуток времени без привязки к конкретному событию. Для понимания так делает OneDrive от Microsoft, он связывается каждые 30 минут, синхронизируя данные. При выполнении последующих шагов по статье он постоянно будет выскакивать и раздражал своим присутствием, поскольку очень походил на малварь, благодаря вышеописанным особенностям. Учитывайте этот момент и прописывайте также и исключения в ходе охоты на угрозы.
Если в ходе проверки вы обнаруживаете задачу, которая обращается к нетипичным директориям вроде C:\ProgramData или C:\Users\Public, и при этом использует скрытый запуск PowerShell с параметрами обхода политик, значит что вы нашли закрепление малваря в системе. Важно не просто удалить такую задачу, но и проанализировать время её создания, чтобы сопоставить этот факт с другими событиями в логах. Такой подход будет более грамотным и целостным.
Главная проблема для Blue Team здесь заключается в объеме данных, потому что в типичной Windows-инфраструктуре работают сотни легитимных задач от обновлений браузеров до системных триггеров телеметрии. В этом шуме хакеру проще всего спрятать свой маяк для закрепления.
Как мы уже демонстрировали в разделе 2.3, эффективный аудит строится на принципе исключения доверенного контекста. Однако, помимо фильтрации по путям, аналитик должен обращать внимание на триггеры запуска. Подозрение должны вызывать задачи, срабатывающие при простое системы или стабильно обращающиеся раз в какой-то промежуток времени без привязки к конкретному событию. Для понимания так делает OneDrive от Microsoft, он связывается каждые 30 минут, синхронизируя данные. При выполнении последующих шагов по статье он постоянно будет выскакивать и раздражал своим присутствием, поскольку очень походил на малварь, благодаря вышеописанным особенностям. Учитывайте этот момент и прописывайте также и исключения в ходе охоты на угрозы.
Если в ходе проверки вы обнаруживаете задачу, которая обращается к нетипичным директориям вроде C:\ProgramData или C:\Users\Public, и при этом использует скрытый запуск PowerShell с параметрами обхода политик, значит что вы нашли закрепление малваря в системе. Важно не просто удалить такую задачу, но и проанализировать время её создания, чтобы сопоставить этот факт с другими событиями в логах. Такой подход будет более грамотным и целостным.
3.3. Registry persistance check
Если планировщик задач можно сравнить с парадным входом, то реестр Windows является сложной сетью скрытых коммуникаций. Ключи автозагрузки Run и RunOnce являются фундаментальным механизмом ОС, который проверяется при каждом старте системы или входе пользователя. Именно здесь делаются дела, когда злоумышленники стремятся создать запись, которая будет выглядеть максимально официально, чтобы не вызвать подозрений у системного администратора при беглом осмотре.
На представленном ниже скрине проведём аудит наиболее критических веток реестра (пользовательской и общесистемной).
В нашем примере мы обнаружили запись с крайне убедительным именем WindowsHealthUpdater, которая при детальном рассмотрении оказывается шляпой. Использование скрытого окна (-WindowStyle Hidden) и запуск внешнего скрипта из общедоступной папки Public - это классические IOC. В отличие от стандартных инструментов мониторинга, которые могут скрыть такие детали, прямой запрос к реестру через PowerShell подсвечивает попытку мимикрии, превращая скрытую угрозу в очевидную цель для безопасника.
Сам скрипт:
На представленном ниже скрине проведём аудит наиболее критических веток реестра (пользовательской и общесистемной).
В нашем примере мы обнаружили запись с крайне убедительным именем WindowsHealthUpdater, которая при детальном рассмотрении оказывается шляпой. Использование скрытого окна (-WindowStyle Hidden) и запуск внешнего скрипта из общедоступной папки Public - это классические IOC. В отличие от стандартных инструментов мониторинга, которые могут скрыть такие детали, прямой запрос к реестру через PowerShell подсвечивает попытку мимикрии, превращая скрытую угрозу в очевидную цель для безопасника.
Сам скрипт:
Get-ItemProperty -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run', 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run' | Select-Object * -ExcludeProperty PSPath, PSParentPath, PSChildName, PSDrive, PSProvider | fl
4. AMSI и ScriptBlock Logging
Если предыдущие главы были про нахождение факта запуска программы, то эта глава посвящена тому, как понять, что именно эта программа делает внутри оперативной памяти. Современные атаки всё чаще становятся бесфайловыми, и PowerShell 7 предоставляет лучшие в своем классе инструменты для их детекта.
4.1. Мониторинг AMSI bypass
AMSI (Antimalware Scan Interface) - это интерфейс, который позволяет Windows и сторонним антивирусам заглядывать внутрь скриптов прямо в момент их исполнения. Главная фишка AMSI в том, что ему неважно, насколько сильно зашифрован код в файле. Как только скрипт расшифровывается в памяти для запуска, AMSI перехватывает его чистый вид и отправляет на проверку антивирусу.
Хакеры, конечно, пытаются отключить этот механизм, однако современная защита научилась распознавать сами попытки такого отключения.
На скриншоте мы видим классическую попытку обойти защиту:
Результат: PowerShell 7 моментально блокирует выполнение, выдавая ParserError. Обратите внимание на красное сообщение внизу: "This script contains malicious content and has been blocked by your antivirus software".
Ключевой момент здесь в том, что вся эта проверка происходит не на уровне файловой системы, а непосредственно в оперативной памяти. Вредоносный код сначала расшифровывается и загружается в RAM, и именно в этот момент AMSI получает доступ к его чистому виду. Это делает бессмысленными многие техники обфускации, так как каким бы ни был исходный код на диске, перед исполнением он неизбежно принимает читаемую форму в памяти процесса PowerShell.
Хакеры, конечно, пытаются отключить этот механизм, однако современная защита научилась распознавать сами попытки такого отключения.
На скриншоте мы видим классическую попытку обойти защиту:
Результат: PowerShell 7 моментально блокирует выполнение, выдавая ParserError. Обратите внимание на красное сообщение внизу: "This script contains malicious content and has been blocked by your antivirus software".
Ключевой момент здесь в том, что вся эта проверка происходит не на уровне файловой системы, а непосредственно в оперативной памяти. Вредоносный код сначала расшифровывается и загружается в RAM, и именно в этот момент AMSI получает доступ к его чистому виду. Это делает бессмысленными многие техники обфускации, так как каким бы ни был исходный код на диске, перед исполнением он неизбежно принимает читаемую форму в памяти процесса PowerShell.
4.2. ScriptBlock log analysis
Даже если атакующему удалось проскочить мимо AMSI, у нас остается ScriptBlock Logging (ID 4104). Эта программа записывает целые блоки кода, которые проходят через движок PowerShell.
Для оперативного анализа этих логов мы используем следующий однострочник:
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" -MaxEvents 20 | Select-Object TimeCreated, Id, Message | Out-GridView
На скриншоте вывода мы видим содержимое ID 4104:
В интерфейсе мы видим перехват событий с ID 4104, которые фиксируют сырой текст выполняемого кода до того, как он будет скрыт или удален из консоли. В поле Message отчетливо видны системные манипуляции, где скрипт проверяет наличие компонентов через Get-WindowsCapability, работает с переменными и выводит финальные статусы в хост. В том же поле зафиксирован реальный текст скрипта, включая переменные и условия. Если хакер запускает зашифрованный Base64-код, ScriptBlock Logging сохраняет его уже в расшифрованном, читаемом виде.
Вам может показаться, что предназначение AMSI и ScriptBlock Logging аналогично, давайте выделим различия:
AMSI действует на этапе выполнения, перехватывая расшифрованный код прямо в оперативной памяти и передавая его антивирусу для возможной блокировки, то есть это механизм превентивной защиты, а ScriptBlock Logging в PowerShell не предотвращает выполнение, он только фиксирует уже обработанные блоки кода в деобфусцированном виде в журналах событий, выступая инструментом наблюдения и последующего анализа.
Для оперативного анализа этих логов мы используем следующий однострочник:
Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" -MaxEvents 20 | Select-Object TimeCreated, Id, Message | Out-GridView
На скриншоте вывода мы видим содержимое ID 4104:
В интерфейсе мы видим перехват событий с ID 4104, которые фиксируют сырой текст выполняемого кода до того, как он будет скрыт или удален из консоли. В поле Message отчетливо видны системные манипуляции, где скрипт проверяет наличие компонентов через Get-WindowsCapability, работает с переменными и выводит финальные статусы в хост. В том же поле зафиксирован реальный текст скрипта, включая переменные и условия. Если хакер запускает зашифрованный Base64-код, ScriptBlock Logging сохраняет его уже в расшифрованном, читаемом виде.
Вам может показаться, что предназначение AMSI и ScriptBlock Logging аналогично, давайте выделим различия:
AMSI действует на этапе выполнения, перехватывая расшифрованный код прямо в оперативной памяти и передавая его антивирусу для возможной блокировки, то есть это механизм превентивной защиты, а ScriptBlock Logging в PowerShell не предотвращает выполнение, он только фиксирует уже обработанные блоки кода в деобфусцированном виде в журналах событий, выступая инструментом наблюдения и последующего анализа.
4.3. Powershell transcription
ScriptBlock Logging фиксирует блоки кода, а Transcription записывет всё, что происходило в консоли. Это идеальный инструмент для форензики, например.
Транскрипт записывает не только вводимые команды, но и их вывод, ошибки и служебную информацию о сессии. На скриншоте вывод программы по ранее заготовленному файлу:
Представленные строки Forensic_Log.txt являются для нас крайне любопытными.
Start time и Username позволяют поминутно сопоставить действия пользователя с логами безопасности, а Process ID дает прямую привязку к сетевой активности и процессам из пункта 3.1. Ключевое значение здесь имеет фиксация PSVersion: 7.5.5. Это доказывает, что современное ядро PowerShell поддается такому же жесткому аудиту, как и классические версии.
Даже если атакующий очистит историю или попытается удалить следы внутри оболочки, транскрипт, сохраненный в защищенную директорию, останется бесспорным пруфом.
Транскрипт записывает не только вводимые команды, но и их вывод, ошибки и служебную информацию о сессии. На скриншоте вывод программы по ранее заготовленному файлу:
Представленные строки Forensic_Log.txt являются для нас крайне любопытными.
Start time и Username позволяют поминутно сопоставить действия пользователя с логами безопасности, а Process ID дает прямую привязку к сетевой активности и процессам из пункта 3.1. Ключевое значение здесь имеет фиксация PSVersion: 7.5.5. Это доказывает, что современное ядро PowerShell поддается такому же жесткому аудиту, как и классические версии.
Даже если атакующий очистит историю или попытается удалить следы внутри оболочки, транскрипт, сохраненный в защищенную директорию, останется бесспорным пруфом.
5. Sysmon Integration
Sysmon предоставляет Blue Team спецу контекст, который невозможно получить из обычного журнала Security. Это делает его незаменимым инструментом для сложной форензики и выявления сложных техник обхода защиты.
5.1. Парсинг Sysmon Events
Прежде чем искать некую крупицу информации в большой базе данных, необходимо разобраться в этой базе. Для начала, что лоично, стоит приступить к группировке событий по их типам, чтобы выявить аномальные всплески активности или наиболее частые векторы работы системы.
Для быстрого обзора текущей ситуации используем следующий однострочник:
Каждая строка здесь может стать конкретным вектором для охоты.
доминирование ID 13 (428 событий) указывает на интенсивную работу с реестром, где могут скрываться механизмы закрепления.
Внушительный объем ID 22 (306 событий) открывает путь к анализу DNS-запросов для поиска скрытых командных центров.
Наличие ID 1 (189 событий) позволяет вычеслить какой процесс запустился. Каждое событие здесь позволяет отследить цепочку запуска, документирует кто породил процесс, с какими параметрами и какой у него уникальный хеш.
В это время ID 11 (55 событий) фиксирует создание файлов, помогая выявить дропперы малвари, маскирующиеся в системных директориях.
Особую ценность имеют ID 3 (8 соединений), поскольку в них содержится минимальный уровень сетевого шума, который позволяет мгновенно подсветить аномальные коннекты PowerShell во внешний мир, т.е. этот ID отслеживает сетевые подключения.
Не менее важным является ID 12 (8 событий), поскольку именно он фиксирует создание или удаление объектов реестра. Это позволяет заметить попытки создать совершенно новые ветки для хранения вредоносных модулей.
В ID 8 (3 события) живёт создание удаленных потоков, что является классическим признак инъекции кода, когда атакующий пытается внедрить свою нагрузку в легитимный процесс вроде explorer.exe.
И наконец ID 5 (1 событие) Тут присходит регистрация завершения процесса. Даже одна такая запись помогает восстановить точный таймлайн атаки и понять, когда именно вредонос закончил свою работу или был принудительно остановлен.
Для быстрого обзора текущей ситуации используем следующий однострочник:
Каждая строка здесь может стать конкретным вектором для охоты.
доминирование ID 13 (428 событий) указывает на интенсивную работу с реестром, где могут скрываться механизмы закрепления.
Внушительный объем ID 22 (306 событий) открывает путь к анализу DNS-запросов для поиска скрытых командных центров.
Наличие ID 1 (189 событий) позволяет вычеслить какой процесс запустился. Каждое событие здесь позволяет отследить цепочку запуска, документирует кто породил процесс, с какими параметрами и какой у него уникальный хеш.
В это время ID 11 (55 событий) фиксирует создание файлов, помогая выявить дропперы малвари, маскирующиеся в системных директориях.
Особую ценность имеют ID 3 (8 соединений), поскольку в них содержится минимальный уровень сетевого шума, который позволяет мгновенно подсветить аномальные коннекты PowerShell во внешний мир, т.е. этот ID отслеживает сетевые подключения.
Не менее важным является ID 12 (8 событий), поскольку именно он фиксирует создание или удаление объектов реестра. Это позволяет заметить попытки создать совершенно новые ветки для хранения вредоносных модулей.
В ID 8 (3 события) живёт создание удаленных потоков, что является классическим признак инъекции кода, когда атакующий пытается внедрить свою нагрузку в легитимный процесс вроде explorer.exe.
И наконец ID 5 (1 событие) Тут присходит регистрация завершения процесса. Даже одна такая запись помогает восстановить точный таймлайн атаки и понять, когда именно вредонос закончил свою работу или был принудительно остановлен.
5.2. Process creation (Event 1 )
В отличие от стандартного лога 4688, Sysmon Event ID 1 предоставляет критически важные метаданные, в том числе хеши исполняемых файлов и полный путь к родительскому процессу. Это позволяет мгновенно проверить файл по базам, по типу VirusTotal, и понять, легитимно ли запущен данный процесс.
Рассмотрим на практике как выглядит event ID 1 изнутри:
Как мы видим, даже стандартный системный процесс вроде svchost.exe раскрывается до мельчайших подробностей, включая его родительский процесс services.exe. Такая прозрачность критически важна, ведь если бы в поле родителя оказался браузер или почтовый клиент, это стало бы неоспоримым доказательством компрометации приложения и попытки внедрения вредоносной службы в ядро системы.
Однако главным козырем Sysmon остается фиксация уникальных криптографических отпечатков файлов. Поле хэшей, содержащее значения MD5 и SHA256, позволяет моментально верифицировать подлинность исполняемого кода. Даже если злоумышленник проявит смекалку и переименует вредоносный бинарник в доверенный системный компонент, его уникальный хеш выдаст истинную природу файла при первой же сверке с VirusTotal и подобными сервисами.
Сам скрипт:
Рассмотрим на практике как выглядит event ID 1 изнутри:
Как мы видим, даже стандартный системный процесс вроде svchost.exe раскрывается до мельчайших подробностей, включая его родительский процесс services.exe. Такая прозрачность критически важна, ведь если бы в поле родителя оказался браузер или почтовый клиент, это стало бы неоспоримым доказательством компрометации приложения и попытки внедрения вредоносной службы в ядро системы.
Однако главным козырем Sysmon остается фиксация уникальных криптографических отпечатков файлов. Поле хэшей, содержащее значения MD5 и SHA256, позволяет моментально верифицировать подлинность исполняемого кода. Даже если злоумышленник проявит смекалку и переименует вредоносный бинарник в доверенный системный компонент, его уникальный хеш выдаст истинную природу файла при первой же сверке с VirusTotal и подобными сервисами.
Сам скрипт:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} -MaxEvents 1 Select-Object TimeCreated, @{N='Image' ; E={$ _. Properties[4]. Value}}, @{N='Cmd' ; E={$ _. Properties [10] . Value}}, @{N='Parent'; E={$ _. Properties [21]. Value}}, @{N='Hashes' ; E={$ _. Properties[17]. Value}} | fl
5.3. Network connection (Event 3 )
Логический анализ процесса не может считаться полным без понимания его сетевой активности, которую Sysmon фиксирует через ID 3. На этом этапе происходит связка конкретного приложения с его внешними коммуникациями, что является ключевым моментом для обнаружения каналов управления и предотвращения утечки данных.
На следующем скрине наглядно показано, как система протоколирует точные сокеты соединений, включая IP-адреса назначения и используемые порты:
Особое внимание здесь, как и везде в нашем ремесле, стоит уделять аномалиям. Если сетевая активность штатных сервисов вроде OneDrive.exe по 443 порту выглядит естественно, то коннект оболочки pwsh.exe к внешнему серверу по порту 8080 является прямым индикатором компрометации.
В условиях реального инцидента, а не лабораторного примера, такая запись в логах становится отправной точкой для изоляции хоста, так как PowerShell в руках атакующего часто выступает инструментом для дальнейших злонамеренных действий.
Сам скрипт:
На следующем скрине наглядно показано, как система протоколирует точные сокеты соединений, включая IP-адреса назначения и используемые порты:
Особое внимание здесь, как и везде в нашем ремесле, стоит уделять аномалиям. Если сетевая активность штатных сервисов вроде OneDrive.exe по 443 порту выглядит естественно, то коннект оболочки pwsh.exe к внешнему серверу по порту 8080 является прямым индикатором компрометации.
В условиях реального инцидента, а не лабораторного примера, такая запись в логах становится отправной точкой для изоляции хоста, так как PowerShell в руках атакующего часто выступает инструментом для дальнейших злонамеренных действий.
Сам скрипт:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=3} -MaxEvents 10 | Select-Object TimeCreated, @{N='Process'; E={$ _. Properties[4]. Value. Split('\') [-1]}}, @{N ='DestIP' ; E={$ _. Properties[14]. Value}}, @{N='Port' ; E={$ _. Properties[16] . Value}} | ft -AutoSize
6. Automated Response
Завершающим этапом любого расследования является локализации угрозы. Когда анализ логов и Sysmon подтвердил наличие вредоносной активности, Blue Team переходит от пассивного наблюдения к активным ответным мерам. Использование PowerShell позволяет автоматизировать этот процесс, сокращая время потенциальной опасности.
6.1. Host isolation скрипт
В процессе реагирования на инцидент фаза локализации является решающей для выживания всей инфраструктуры.
Когда анализ подтвердил наличие активного вредоноса, перед специалистом встает выбор между физическим отключением питания и изолированием системы программно.
Профессиональный подход Blue Team подразумевает именно программную изоляцию через Windows Firewall. Это позволяет сохранить систему живой для дальнейшего исследования, не теряя бесценные улики в оперативной памяти, такие как дампы процессов, открытые сетевые сессии и ключи шифрования, которые мгновенно исчезли бы при выключении.
Главная цель здесь в мгновенном обрубании возможности атакующего перемещаться внутри системы.
На практике процесс изоляции начинается с выявления четких индикаторов угрозы, таких как зацикленное обращение процесса к удаленному серверу, как на этом примере:
Такие регулярные, повторяющиеся запросы в логах свидетельствуют о работе маяка, ожидающего команд от хакера.
Оставлять подобную активность без внимания категорически нельзя, это приведет к полному контролю атакующего над вашей инфраструктуры. Чтобы нейтрализовать этот риск, применяется жесткая политика блокировки исходящего трафика, результат которой наглядно продемонстрирован на следующем скрине:
Справа в консоли мы наблюдаем мгновенное появление ошибок соеденения с удалённым сервером. На этом этапе злоумышленник теряет доступ к управлению вредоносом.
Финальным этапом возведения защитного периметра становится блокировка входящего трафика, показанная на следующем скрине:
Создание правила New-NetFirewallRule с направлением Inbound и окончательным блокированием. Это критически важно для предотвращения распространения заражения, так как даже если в сети уже есть другие скомпрометированные устройства, они не смогут достучаться до изолированного узла для доставки новых модулей или эксплойтов. В итоге хост оказывается в полном информационном вакууме, становясь безопасным для остальной сети и одновременно доступным для детального исследования безопасниками.
Скрипт блокировки выходыщего трафика:
Когда анализ подтвердил наличие активного вредоноса, перед специалистом встает выбор между физическим отключением питания и изолированием системы программно.
Профессиональный подход Blue Team подразумевает именно программную изоляцию через Windows Firewall. Это позволяет сохранить систему живой для дальнейшего исследования, не теряя бесценные улики в оперативной памяти, такие как дампы процессов, открытые сетевые сессии и ключи шифрования, которые мгновенно исчезли бы при выключении.
Главная цель здесь в мгновенном обрубании возможности атакующего перемещаться внутри системы.
На практике процесс изоляции начинается с выявления четких индикаторов угрозы, таких как зацикленное обращение процесса к удаленному серверу, как на этом примере:
Такие регулярные, повторяющиеся запросы в логах свидетельствуют о работе маяка, ожидающего команд от хакера.
Оставлять подобную активность без внимания категорически нельзя, это приведет к полному контролю атакующего над вашей инфраструктуры. Чтобы нейтрализовать этот риск, применяется жесткая политика блокировки исходящего трафика, результат которой наглядно продемонстрирован на следующем скрине:
Справа в консоли мы наблюдаем мгновенное появление ошибок соеденения с удалённым сервером. На этом этапе злоумышленник теряет доступ к управлению вредоносом.
Финальным этапом возведения защитного периметра становится блокировка входящего трафика, показанная на следующем скрине:
Создание правила New-NetFirewallRule с направлением Inbound и окончательным блокированием. Это критически важно для предотвращения распространения заражения, так как даже если в сети уже есть другие скомпрометированные устройства, они не смогут достучаться до изолированного узла для доставки новых модулей или эксплойтов. В итоге хост оказывается в полном информационном вакууме, становясь безопасным для остальной сети и одновременно доступным для детального исследования безопасниками.
Скрипт блокировки выходыщего трафика:
New-NetFirewallRule -DisplayName "HOST_ISOLATION_OUT" -Direction Outbound -Action Block -Description "Emergency Isolation Out"Скрипт блокировки входящего трафика:
New-NetFirewallRule -DisplayName "HOST_ISOLATION_IN" -Direction Inbound -Action Block -Description "Emergency Isolation"
6.2. IP blocking (firewall rules)
Если изоляция хоста в предыдущем пункте была массированная и беспощадная, то блокировка IP представляется куда аккуратнее.
В реальных условиях часто возникают ситуации, когда полностью изолировать критически важный сервер нельзя, но при этом у нас на руках есть четкий список адресов командных центров хакера. В этом случае PowerShell позволяет действовать точечно, сохраняя работоспособность бизнес-процессов.
Рассмотрим же на практике, как выполнять такую задачу. На следующем скрине зафиксирована стабильная сетевая активность с внешними узлами, что служит критически важной отправной точкой для расследования:
Этот этап необходим, чтобы подтвердить наличие связи до вмешательства и иметь неоспоримые доказательства того, что последующие изменения в работе сети вызваны именно нашими действиями с целью нейтрализации угрозы.
Прописываем своевременное Block_Malicious_IP, направленное на конкретный скомпрометированный адрес:
И получаем получаем следующий кадр, где наблюдаем избирательную блокировку в действии. В то время как основной канал связи с доверенными ресурсами (справа верхнее окно) продолжает работать без задержек, любые запросы к подозрительному узлу мгновенно прерываются с ошибкой General failure (справа нижнее окно).Согласитесь, выглядит крайне аккуратно. Такая своевременная команда приходится очень кстати, когда не в коем случае нельзя полностью изолировать хост.
В реальных условиях часто возникают ситуации, когда полностью изолировать критически важный сервер нельзя, но при этом у нас на руках есть четкий список адресов командных центров хакера. В этом случае PowerShell позволяет действовать точечно, сохраняя работоспособность бизнес-процессов.
Рассмотрим же на практике, как выполнять такую задачу. На следующем скрине зафиксирована стабильная сетевая активность с внешними узлами, что служит критически важной отправной точкой для расследования:
Этот этап необходим, чтобы подтвердить наличие связи до вмешательства и иметь неоспоримые доказательства того, что последующие изменения в работе сети вызваны именно нашими действиями с целью нейтрализации угрозы.
Прописываем своевременное Block_Malicious_IP, направленное на конкретный скомпрометированный адрес:
И получаем получаем следующий кадр, где наблюдаем избирательную блокировку в действии. В то время как основной канал связи с доверенными ресурсами (справа верхнее окно) продолжает работать без задержек, любые запросы к подозрительному узлу мгновенно прерываются с ошибкой General failure (справа нижнее окно).Согласитесь, выглядит крайне аккуратно. Такая своевременная команда приходится очень кстати, когда не в коем случае нельзя полностью изолировать хост.
6.3. Process termination по IOC
Когда сетевые каналы перекрыты и атакующий потерял управление, наступает время ликвидировать основную движущую силу атаки внутри операционной системы. Используя данные, полученные в ходе мониторинга IOC, мы выполняем принудительное завершение работы вредоноса.
Финальный скрин во славу завершение операции (в данном случае учебного враждебного блокнота):
Использование команды Stop-Process с параметром -PassThru является важным моментом, именно благодаря нему мы видим объект процесса непосредственно в момент его уничтожения.
Это служит неоспоримым доказательством того, что PowerShell успешно перехватил и нейтрализовал цель. В консоли остаются только сухие технические факты, а вредоносный код полностью остановлен, фаза активного реагирования успешно завершена.
Финальный скрин во славу завершение операции (в данном случае учебного враждебного блокнота):
Использование команды Stop-Process с параметром -PassThru является важным моментом, именно благодаря нему мы видим объект процесса непосредственно в момент его уничтожения.
Это служит неоспоримым доказательством того, что PowerShell успешно перехватил и нейтрализовал цель. В консоли остаются только сухие технические факты, а вредоносный код полностью остановлен, фаза активного реагирования успешно завершена.
7. Hardening и Audit
После активной фазы зачистки наступает этап пост-инцидентного анализа. Мы не можем просто вернуть хост в строй, не убедившись, что атакующий не оставил следов в политиках или правах доступа. На этом этапе PowerShell хорого годится как сканер стандартов и важных настроек.
7.1. GPO audit
Для первичного аудита системы идеально подходит создание кастомного объекта PowerShell, который за один проход собирает статус критических параметров защиты.
На следующих скриншотах наглядно показана разница между защищенным (рис. 1.) и скомпрометированным (рис. 2.) состоянием:
рис. 1
рис. 2
В первом случае мы видим активное логирование блоков скриптов и строгую политику выполнения RemoteSigned, а во втором полную слепоту системы при режиме обхода политик.
ScriptBlockLogging также в строю:
На следующих скриншотах наглядно показана разница между защищенным (рис. 1.) и скомпрометированным (рис. 2.) состоянием:
рис. 1
рис. 2
В первом случае мы видим активное логирование блоков скриптов и строгую политику выполнения RemoteSigned, а во втором полную слепоту системы при режиме обхода политик.
ScriptBlockLogging также в строю:
7.2. ACL verification
Одним из скрытых методов сохранения присутствия является модификация списков контроля доступа (ACL) к системным директориям. Проверка прав на папку C:\Windows\Temp вскрывает опасную конфигурацию:
Здесь наличие прав FullControl для группы Everyone фактически превращает системную директорию в общедоступную песочницу для любого вредоносного кода.Такие дыры обязательно нужно детектить, это позволит вовремя обнаружить подготовленные нападающим пути для повторного заражения или закрепления.
Здесь наличие прав FullControl для группы Everyone фактически превращает системную директорию в общедоступную песочницу для любого вредоносного кода.Такие дыры обязательно нужно детектить, это позволит вовремя обнаружить подготовленные нападающим пути для повторного заражения или закрепления.
7.3. Baseline comparison
Финальный этап аудита заключается в приведении всех модифицированных прав к утвержденному базовому уровню, который также зовётся «Baseline».
Как показано на следующем изображении, после исправления прав доступа из списка исчезают лишние группы, а управление возвращается легитимным системным аккаунтам и администраторам:
Такая сверка с эталоном является финальным этапом. Только когда права доступа и политики соответствуют доверенному состоянию, процесс Hardening считается завершенным, а риск рецидива становится минимальным.
Что же, мы проделали поистине фундаментальную работу.
Надеюсь, что материал был для вас полезным и интересным.
Как показано на следующем изображении, после исправления прав доступа из списка исчезают лишние группы, а управление возвращается легитимным системным аккаунтам и администраторам:
Такая сверка с эталоном является финальным этапом. Только когда права доступа и политики соответствуют доверенному состоянию, процесс Hardening считается завершенным, а риск рецидива становится минимальным.
Что же, мы проделали поистине фундаментальную работу.
Надеюсь, что материал был для вас полезным и интересным.
Удачи!
Вложения
Последнее редактирование модератором:
