Во времена, когда я писал серию статей о тестах на проникновение, чтобы помочь человечеству в борьбе с хакерами, мне попалась информация о некоторых интересных командлетах и техниках PowerShell. Я сделал выдающееся открытие: PowerShell является самостоятельным средством защиты. Похоже, самое время начать новую серию публикаций о PowerShell.

В этих публикациях мы будем придерживаться мнения, что, хотя PowerShell не заменит специальные платформы безопасности (сотрудники Varonis могут вздохнуть с облегчением), это средство поможет ИТ-специалистам отслеживать угрозы и принимать другие меры для обеспечения безопасности. Кроме того, ИТ-отдел начнет ценить чудеса специализированных платформ безопасности, таких как наше решение Metadata Framework. PowerShell может выполнять интересные задачи по обеспечению безопасности в малых масштабах, но это средство не обладает характеристиками для работы со всей инфраструктурой.

Важное событие

Для начала рассмотрим использование PowerShell в качестве инструмента мониторинга системы для отслеживания файлов, процессов и действий пользователей.

Перед тем как начать проклинать меня, позвольте сказать, что я прекрасно знаю, что любой командный язык операционной системы можно использовать для отслеживания событий на системном уровне. Любой младший системный администратор может настроить, к примеру, скрипт оболочки Linux для опроса каталога, чтобы узнать, был ли обновлен файл, или для получения списка запущенных процессов, чтобы найти среди них нестандартные.

Сейчас речь не об этом.

Вместо этого PowerShell предоставляет непосредственное событийно-управляемое отслеживание на основе доступа операционной системы к изменениям нижнего уровня. Это равнозначно получению всплывающих уведомлений о последних событиях на новостном сайте вместо необходимости обновлять страницу вручную.

При этом PowerShell не будет работать без остановки, загружая циклы процессора. Скрипт активируется, когда происходит событие (изменение файла или вход в систему нового пользователя). Такое отслеживание безопасности гораздо эффективнее опросов методом подбора.

Ниже я объясню, как это делается.

Каждый, кто, как и я, изучал операционные системы, знает, что есть граница между процессами на уровне пользователя и процессами на уровне системы.

Операционная система (неважно, Linux или Windows) обрабатывает действия устройства на нижнем уровне, от чтения диска до получения пакетов, и скрывает это от рядовых приложений, запущенных на ПК.

Таким образом, если запустить любимое приложение для обработки текстов и просмотреть первую страницу документа, вся операция будет выглядеть, как плавное и синхронное действие. Однако в действительности происходят всевозможные события (поиск на диске, чтение дисковых блоков, отправка символов на экран и т. д.), которые намеренно скрыты от нас. За это можно благодарить Билла Гейтса.

Раньше только суровые системные инженеры знали об обработке событий на нижнем уровне. Теперь программисты PowerShell могут с удовольствием поделиться этой информацией.

Инструментальный язык ОС

Рассмотрим инструментарий управления Windows (WMI), который является попыткой Microsoft обеспечить последовательный просмотр объектов операционной системы.

Служба WMI, которой всего несколько лет, является частью крупной системы управления предприятием через Интернет (WBEM), предназначенной для стандартизации сведений, полученных от маршрутизаторов, переключателей, массивов хранения данных, а также операционных систем.

Как же выглядит и работает WMI?

Для наших целей инструментарий представляет собой язык запросов, как SQL, но вместо доступа к столбцам баз данных он дает комплексную информацию об операционной системе в виде иерархии классов WMI. Разумеется, язык запросов называется WQL.

В Windows имеется служебная программа WBEMTest, с помощью которой можно взаимодействовать с WQL. На изображении ниже показан запрос объекта Win32_Process, содержащий информацию о текущем запущенном процессе.


Тренировочная работа с WQL в WBEMTest

Фактически это программный эквивалент монитора задач Windows. Впечатляет, не так ли? Если хотите узнать больше о WQL, загрузите превосходную электронную книгу Рави Чаганти (Ravi Chaganti), посвященную этой теме.

PowerShell и командлет Register-WmiEvent

Но это еще не все. От тренировочных заданий в WBEMTest можно перейти к запросам непосредственно в PowerShell.

Для этого подойдет командлет PowerShell Get-WMIObject. Он позволяет отправлять запрос WQL непосредственно в виде параметра.

На изображении ниже показаны первые несколько результатов запуска select Name, ProcessId, CommandLine from Win32_Process в тестовой среде AWS.


gwmi — это Get-WmiObject в PowerShell

Результат немного ненадежен, так как есть некоторые скрытые свойства, имеющие отношение к основному классу регистрации данных. Кроме того, этот командлет выдает внушительный список в консоли.

Для улучшения работы с Win32_Process я переместил результат запроса в Out-GridView — командлет PowerShell, который форматирует данные в аккуратную таблицу на основе графического интерфейса.



Неплохо для строки кода PowerShell. Но служба WMI способна на большее, чем просто запрашивать объекты ОС.

Как я упоминал ранее, она дает доступ к соответствующим событиям этих объектов. В WMI эти события ориентировочно разделены на три типа: создание, изменение и удаление.

До выхода PowerShell 2.0 доступ к этим событиям приходилось получать запутанным способом: создавая множество различных объектов, после чего происходило синхронное зависание, так что это не была настоящая асинхронная обработка событий. Чтобы узнать подробности, прочитайте публикацию MS Technet.

Теперь командлет Register-WmiEvent в PowerShell 2.0 позволяет реагировать на события в более приемлемой манере. Иными словами, когда происходит событие, срабатывает вызов, который можно зарегистрировать.

Вернемся к моей вымышленной (и уже знаменитой) компании Acme, чья ИТ-инфраструктура работает в среде AWS.

Системный администратор (назовем его Бобом) время от времени замечает, что место на сервере Salsa заканчивается. Он подозревает, что генеральный директор Acme Тед Блоутли загружает большие файлы, такие как аудиозаписи, в один из каталогов Боба, а затем перемещает на свой сервер Taco.

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

Чтобы сделать это, ему нужно работать с классом CIM_DataFile. Вместо получения доступа к процессам, как мы делали ранее, Боб использует этот класс для соединения с метаданными основного файла.


В PowerShell можно получить непосредственный доступ к объекту CIM_DataFile

В качестве Боба я создал следующий скрипт Register-WmiEvent, который будет отправлять уведомления в консоль при создании большого файла в основном каталоге.

Register-WmiEvent -Query "SELECT * FROM __InstanceModificationEvent WITHIN 5 WHERE TargetInstance isa 'CIM_DataFile' and TargetInstance.FileSize > 2000000 and TargetInstance.Path = '\\Users\\bob\\' and targetInstance.Drive = 'C:' "-sourceIdentifier "Accessor3" -Action { Write-Host "Large file" $EventArgs.NewEvent.TargetInstance.Name "was created”}

Запуск этого скрипта непосредственно в консоли Salsa активирует команду Register-WmiEvent в фоновом режиме, назначая ей номер задания. Дальнейшее взаимодействие происходит только при возникновении события.

В следующей публикации я расскажу об этом подробнее. Фактически я использую WQL для запроса из каталога \Users\bob любого объекта CIM_DataFile, превышающего 2 млн байтов. При создании файла, соответствующего условиям, появится уведомление, для которого активируется InstanceModificationEvent.

В любом случае, играя роль Боба, я запустил скрипт из командной строки PowerShell, а затем, как и Тед из нашей истории, я скопировал большой файл MP4 в каталог Боба. Результат вы можете увидеть ниже.



Теперь мы знаем, что Тед — фанат Мелоди Гардо. Кто бы мог подумать!

В публикации были продемонстрированы некоторые удивительные возможности использования средства PowerShell в качестве инструмента для обнаружения угроз и небольшого анализа поведения.

Мы продолжим изучать эти аспекты в следующих статьях.