И снова здравствуйте. В преддверии старта курса «Пентест. Практика тестирования на проникновение» перевели для вас еще один интересный материал.
В этой статье мы собираемся разобраться в возможностях широко известных утилит мониторинга процессов и продемонстрировать, как использовать технологию, лежащую в основе этих инструментов, для наступательных операций Red Team.
Хорошее техническое понимание системы, на которое мы опираемся, является ключевым критерием принятия решений о том, каким будет следующий шаг операции. Сбор и анализ данных о запущенных процессах в скомпрометированных системах дает нам огромное количество информации и помогает понять, как устроена IT-инфраструктура целевой организации. Помимо этого, периодически запрашиваемые данные о процессах помогают нам реагировать на изменения в окружающей среде и получать сигналы-триггеры о начале расследования.
Чтобы иметь возможность собирать детализированные данные о процессах в скомпрометированных конечных точках, мы создали набор инструментов, который собрал воедино мощь продвинутых процессных утилит и фреймворков С2 (таких как Cobalt Strike).
Инструменты (и их исходный код) можно найти здесь.
Для начала мы разберемся, какие утилиты можно использовать для сбора информации о процессах компьютера на Windows. Затем мы узнаем, каким образом эти утилиты собирают информацию, чтобы впоследствии использовать их в инструментарии Red Team.
Операционная система Windows оснащена множеством готовых утилит для администрирования системы. Несмотря на то, что большинство предоставленных инструментов подходят для целей базового системного администрирования, некоторые из них не обладают необходимыми функциями для расширенного поиска неисправностей и мониторинга. Например, диспетчер задач Windows дает нам базовую информацию обо всех процессах, запущенных в системе, но что делать, если нам требуется более подробная информация, такая, как дескрипторы объектов, сетевые подключения или же модули, загруженные в рамках определенного процесса?
Для сбора подобной информации имеется более продвинутый инструмент. Например, системные утилиты пакета Sysinternals. Как участник Red Team с большим опытом в сетевом и системном администрировании, я всегда был большим поклонником Sysinternals.
При устранении неполадок в медленно работающей серверной системе или зараженном клиентском компьютере, я чаще всего начинал устранение неполадок с помощью таких инструментов, как Process Explorer или Procmon.
С точки зрения цифровой криминалистики эти инструменты также представляются очень полезными для проведения базового динамического анализа образцов вредоносных программ и поиска артефактов в зараженных системах. Так почему же эти инструменты так популярны среди системных администраторов, а также специалистов по безопасности? Давайте разберемся в этом, углубившись в некоторую информацию о процессе, которую мы можем получить с помощью инструмента Process Explorer.
Первое, что мы видим при запуске Process Explorer – это список/дерево всех запущенных процессов системы. Это дает нам информацию об именах процессов, их идентификаторах, контексте пользователя и уровне целостности информации о процессе и версии. Дополнительную информацию также можно отразить, настроив столбцы соответствующим образом.
Если мы задействуем нижнюю панель, то сможем просмотреть все модули, загруженные определенным процессом, или переключиться на просмотр дескрипторов, чтобы ознакомиться со всеми именованными объектами-дескрипторами, которые используются процессом:
Просмотр модулей может быть полезен при поиске вредоносных библиотек, загружаемых в процессе или же для Red Team – это активный продукт безопасности (например, EDR), который внедрил модуль подключения по API в режиме пользователя.
Переключение на просмотр дескрипторов позволяет ознакомиться с типом и именем всех именованных объектов, используемых в процессе. Это может быть полезно, чтобы узнать, какие файлы и разделы реестра открыты, какие именованные каналы используются для межпроцессного взаимодействия.
Если вы щелкнете дважды на имя процесса, то появится окно с более подробной информацией. Давайте рассмотрим некоторые вкладки, чтобы узнать о дополнительных свойствах объекта:
Вкладка Image показывает информацию о бинарном пути, рабочем каталоге и параметрах командной строки. Помимо этого, в ней видна информация о пользовательском контексте, родительском процессе, типе образа (x86 или x64) и многое другое.
Вкладка Threads содержит информацию о запущенных потоках в процессе. При выборе потока и последующем нажатии на него, кнопка stack отразит стек вызовов для данного конкретного потока. Для просмотра потоков/вызовов, запущенных в режиме ядра, Process Explorer использует драйвер ядра, который устанавливается при работе в режиме повышенных полномочий.
С точки зрения DFIR, информация о потоках полезна для обнаружения инъекций в память, например, при угрозе безфайловых вирусов. Таким образом, потоки, не подкрепленные файлами на диске, могут сигнализировать о подозрительном поведении. Чтобы получить больше информации о потоках и памяти, я настоятельно рекомендую обратить внимание на инструмент Process Hacker.
Еще одна интересная вкладка в Process Explorer — это вкладка TCP/IP. На ней вы увидите все сетевые подключения, связанные с этим процессом. С точки зрения атаки это может быть полезно для понимания, когда соединение осуществляется из скомпрометированной системы. Входящий сеанс удаленного взаимодействия PowerShell или RDP-сессия может служить сигналом к тому, что расследование уже начато.
Теперь, когда мы узнали немного интересного о процессах, и об информации, которую мы можем о них собрать с помощью Process Explorer, вы можете задаться вопросом, как получить доступ к этой информации из наших любимых фреймворков C2. Конечно, мы могли бы воспользоваться PowerShell, поскольку это дало бы нам возможность использовать мощный скриптовый язык и Windows API. Однако сегодня PowerShell находится под неустанным надзором службы безопасности, поэтому мы стараемся избегать этого метода.
В Cobalt Strike мы можем использовать команду ps в контексте биконов. Эта команда отображает основную информацию о процессе исходя из всех процессов, запущенных в системе. В сочетании со скриптом
Выходные данные команды ps полезны для быстрой сортировки запущенных процессов, но они не содержат подробной информации, которая помогла бы лучше разобраться в системе. Чтобы собрать более детализированную информацию, мы создали собственные утилиты для получения информации о процессах. С их помощью мы можем собрать и обогатить информацию, полученную из скомпрометированных систем.
Непросто реплицировать функциональные возможности и информацию, предоставляемую таким инструментом как Process Explorer. Для начала нам нужно выяснить как эти инструменты работают под капотом (и в пользовательском режиме), затем нам нужно понять, как лучше отражать эту информацию в консоли, а не в графическом интерфейсе.
После анализа исходного кода стало понятно, что многие низкоуровневые средства предоставления системной информации в значительной степени основываются на нативном API NtQuerySystemInformation. Несмотря на то, что API и связанные с ним структуры не полностью задокументированы, этот API позволяет собирать большое количество информации о системе Windows. Таким образом, используя NtQuerySystemInformation в качестве отправной точки для сбора информации о процессах, запущенных в системе, мы будем использовать PEB отдельных процессов для сбора детализированной информации о каждом из них. С помощью API NtQueryInformationProcess мы сможем прочитать структуру
Используя эти API в качестве фундамента нашего кода, мы написали следующие инструменты для получения информации о процессах:
Все эти инструменты написаны на С как рефлективные DLL и могут быть рефлективно внедрены в порожденный процесс с помощью С2 фреймворка, такого как Cobalt Strike (или любого другого фреймворка, который поддерживает рефлективные DLL-инъекции). Для Cobalt Strike мы добавили скрипт-агрессор, который можно использовать для загрузки инструментов с помощью менеджера скриптов Cobalt Strike.
Давайте рассмотрим каждый конкретный инструмент, запущенный в Cobalt Strike, чтобы продемонстрировать функциональность и показать какую информацию можно собрать с его помощью:
Этот инструмент показывает подробный список всех процессов, запущенных в системе. Выходные данные можно сравнить с информацией на главном экране Process Explorer. Psx выводит имя процесса, его id, родительский PID, время создания и информацию, связанную с бинарными файлами процесса (архитектуру, название компании, версии и т.д.). Как вы видите, он также отображает кое-какую интересную информацию активного ядра системы, например, базовый адрес ядра, который полезен при эксплуатации ядра (например, для вычисления смещений ROP-гаджетов). Всю эту информацию можно собрать из обычного пользовательского контекста (без повышения прав).
Если у нас достаточно разрешений, чтобы открыть дескриптор процесса, можно прочитать дополнительную информацию, такую как контекст пользователя и уровень целостности его токена. Перечисление PEB и связанных структур позволяет получить информацию о пути образа и параметры командной строки:
Как вы могли заметить, мы читаем и выводим информацию о версии из бинарных образов процесса, например, название компании и описание. Зная название компании, можно легко перечислить все активные продукты безопасности в системе. С помощью этого инструмента мы сравниваем названия компаний всех активных процессов со списком известных поставщиков продуктов безопасности и выводим результаты:
Этот инструмент отражает информацию о работающем ядре, включая все загруженные модули драйверов. Как и инструмент Psx, он также предоставляет сводку обо всех загруженных модулях ядра от известных продуктов безопасности.
Этот инструмент использует те же методы для вывода информации об активных процессах, что и Psx, за исключением того, что он отображает только процессы с активным сетевым соединением (IPv4, IPv6 TCP, RDP, ICA):
Этот инструмент можно использовать для получения подробных сведений о конкретном процессе. Он будет отображать список всех модулей (DLL), используемых процессом и сетевым соединением:
То же самое, что и Psm, но вместо загруженных модулей, показывает список дескрипторов процесса:
Последний, но не менее важный инструмент Psw. Этот инструмент покажет список процессов с активными дескрипторами окон, тех, которые открыты на рабочем столе пользователя, включая заголовки окон. Это полезно для определения того, какие графические интерфейсы приложений открываются пользователем без необходимости создавать скриншоты рабочего стола:
Вы можете задаться вопросом: «И как же это все поможет нам в операциях по наступлению?» После получения доступа к скомпрометированному активу мы обычно используем эту информацию для следующих целей:
После первой компрометации вы можете периодически запрашивать подобную информацию о процессах и приступить к созданию триггеров. Например, мы автоматически вводим эту информацию в RedELK. Затем можно создать оповещения о подозрительных изменениях в информации о процессе, таких как:
В этой статье мы показали, как такие инструменты, как Sysinternals Process Explorer, можно использовать для получения подробной информации о процессах, запущенных в системе, и как эта информация может помочь администраторам и специалистам по безопасности устранять неполадки и проверять систему на наличие проблем с безопасностью или производительностью.
Эта же информация также актуальна и полезна для Red Team, которые имеют доступ к скомпрометированным системам во время работы. Она помогает лучше понять систему и IT-инфраструктуру вашей цели, а периодический опрос такой системы позволяет Red Team реагировать на возможные изменения среды (например, триггер расследования).
Мы реплицировали некоторые функциональные возможности, предоставляемые такими инструментами, как Process Explorer, поэтому мы можем использовать ту же информацию в наступательных операциях. Для этого были созданы несколько инструментов мониторинга процессов, которые могут быть использованы в рамках фреймворка С2, например Cobalt Strike. Мы показали, как пользоваться этими инструментами и какую информацию с помощью них можно собрать.
Эти инструменты доступны на нашей GitHub-странице и готовы к использованию в составе Cobalt Strike.
Узнать подробнее о курсе.
В этой статье мы собираемся разобраться в возможностях широко известных утилит мониторинга процессов и продемонстрировать, как использовать технологию, лежащую в основе этих инструментов, для наступательных операций Red Team.
Хорошее техническое понимание системы, на которое мы опираемся, является ключевым критерием принятия решений о том, каким будет следующий шаг операции. Сбор и анализ данных о запущенных процессах в скомпрометированных системах дает нам огромное количество информации и помогает понять, как устроена IT-инфраструктура целевой организации. Помимо этого, периодически запрашиваемые данные о процессах помогают нам реагировать на изменения в окружающей среде и получать сигналы-триггеры о начале расследования.
Чтобы иметь возможность собирать детализированные данные о процессах в скомпрометированных конечных точках, мы создали набор инструментов, который собрал воедино мощь продвинутых процессных утилит и фреймворков С2 (таких как Cobalt Strike).
Инструменты (и их исходный код) можно найти здесь.
Внутренние системные утилиты Windows
Для начала мы разберемся, какие утилиты можно использовать для сбора информации о процессах компьютера на Windows. Затем мы узнаем, каким образом эти утилиты собирают информацию, чтобы впоследствии использовать их в инструментарии Red Team.
Операционная система Windows оснащена множеством готовых утилит для администрирования системы. Несмотря на то, что большинство предоставленных инструментов подходят для целей базового системного администрирования, некоторые из них не обладают необходимыми функциями для расширенного поиска неисправностей и мониторинга. Например, диспетчер задач Windows дает нам базовую информацию обо всех процессах, запущенных в системе, но что делать, если нам требуется более подробная информация, такая, как дескрипторы объектов, сетевые подключения или же модули, загруженные в рамках определенного процесса?
Для сбора подобной информации имеется более продвинутый инструмент. Например, системные утилиты пакета Sysinternals. Как участник Red Team с большим опытом в сетевом и системном администрировании, я всегда был большим поклонником Sysinternals.
При устранении неполадок в медленно работающей серверной системе или зараженном клиентском компьютере, я чаще всего начинал устранение неполадок с помощью таких инструментов, как Process Explorer или Procmon.
С точки зрения цифровой криминалистики эти инструменты также представляются очень полезными для проведения базового динамического анализа образцов вредоносных программ и поиска артефактов в зараженных системах. Так почему же эти инструменты так популярны среди системных администраторов, а также специалистов по безопасности? Давайте разберемся в этом, углубившись в некоторую информацию о процессе, которую мы можем получить с помощью инструмента Process Explorer.
Использование Process Explorer
Первое, что мы видим при запуске Process Explorer – это список/дерево всех запущенных процессов системы. Это дает нам информацию об именах процессов, их идентификаторах, контексте пользователя и уровне целостности информации о процессе и версии. Дополнительную информацию также можно отразить, настроив столбцы соответствующим образом.
Если мы задействуем нижнюю панель, то сможем просмотреть все модули, загруженные определенным процессом, или переключиться на просмотр дескрипторов, чтобы ознакомиться со всеми именованными объектами-дескрипторами, которые используются процессом:
Просмотр модулей может быть полезен при поиске вредоносных библиотек, загружаемых в процессе или же для Red Team – это активный продукт безопасности (например, EDR), который внедрил модуль подключения по API в режиме пользователя.
Переключение на просмотр дескрипторов позволяет ознакомиться с типом и именем всех именованных объектов, используемых в процессе. Это может быть полезно, чтобы узнать, какие файлы и разделы реестра открыты, какие именованные каналы используются для межпроцессного взаимодействия.
Если вы щелкнете дважды на имя процесса, то появится окно с более подробной информацией. Давайте рассмотрим некоторые вкладки, чтобы узнать о дополнительных свойствах объекта:
Вкладка Image показывает информацию о бинарном пути, рабочем каталоге и параметрах командной строки. Помимо этого, в ней видна информация о пользовательском контексте, родительском процессе, типе образа (x86 или x64) и многое другое.
Вкладка Threads содержит информацию о запущенных потоках в процессе. При выборе потока и последующем нажатии на него, кнопка stack отразит стек вызовов для данного конкретного потока. Для просмотра потоков/вызовов, запущенных в режиме ядра, Process Explorer использует драйвер ядра, который устанавливается при работе в режиме повышенных полномочий.
С точки зрения DFIR, информация о потоках полезна для обнаружения инъекций в память, например, при угрозе безфайловых вирусов. Таким образом, потоки, не подкрепленные файлами на диске, могут сигнализировать о подозрительном поведении. Чтобы получить больше информации о потоках и памяти, я настоятельно рекомендую обратить внимание на инструмент Process Hacker.
Еще одна интересная вкладка в Process Explorer — это вкладка TCP/IP. На ней вы увидите все сетевые подключения, связанные с этим процессом. С точки зрения атаки это может быть полезно для понимания, когда соединение осуществляется из скомпрометированной системы. Входящий сеанс удаленного взаимодействия PowerShell или RDP-сессия может служить сигналом к тому, что расследование уже начато.
Использование рассмотренных методов для нападения
Теперь, когда мы узнали немного интересного о процессах, и об информации, которую мы можем о них собрать с помощью Process Explorer, вы можете задаться вопросом, как получить доступ к этой информации из наших любимых фреймворков C2. Конечно, мы могли бы воспользоваться PowerShell, поскольку это дало бы нам возможность использовать мощный скриптовый язык и Windows API. Однако сегодня PowerShell находится под неустанным надзором службы безопасности, поэтому мы стараемся избегать этого метода.
В Cobalt Strike мы можем использовать команду ps в контексте биконов. Эта команда отображает основную информацию о процессе исходя из всех процессов, запущенных в системе. В сочетании со скриптом
@r3dQu1nn ProcessColor, этот способ, вероятно, окажется наилучшим для получения данных о процессе. Выходные данные команды ps полезны для быстрой сортировки запущенных процессов, но они не содержат подробной информации, которая помогла бы лучше разобраться в системе. Чтобы собрать более детализированную информацию, мы создали собственные утилиты для получения информации о процессах. С их помощью мы можем собрать и обогатить информацию, полученную из скомпрометированных систем.
Инструменты Ps
Непросто реплицировать функциональные возможности и информацию, предоставляемую таким инструментом как Process Explorer. Для начала нам нужно выяснить как эти инструменты работают под капотом (и в пользовательском режиме), затем нам нужно понять, как лучше отражать эту информацию в консоли, а не в графическом интерфейсе.
После анализа исходного кода стало понятно, что многие низкоуровневые средства предоставления системной информации в значительной степени основываются на нативном API NtQuerySystemInformation. Несмотря на то, что API и связанные с ним структуры не полностью задокументированы, этот API позволяет собирать большое количество информации о системе Windows. Таким образом, используя NtQuerySystemInformation в качестве отправной точки для сбора информации о процессах, запущенных в системе, мы будем использовать PEB отдельных процессов для сбора детализированной информации о каждом из них. С помощью API NtQueryInformationProcess мы сможем прочитать структуру
PROCESS_BASIC_INFORMATION, используя дескриптор процесса, и найти PebBaseAddress. Затем мы используем NtReadVirtualMemory API для чтения структуры RTL_USER_PROCESS_PARAMETERS, которая позволит нам узнать параметры ImagePathName и CommandLine процесса.Используя эти API в качестве фундамента нашего кода, мы написали следующие инструменты для получения информации о процессах:
- Psx: показывает подробный список всех процессов, запущенных в системе.
- Psk: показывает информацию о ядре, включая загруженные драйверы.
- Psc: показывает подробный список всех процессов с установленными TCP-соединениями.
- Psm: показывает подробную информацию о модуле из конкретного идентификатора процесса (загруженные модули или сетевые подключения, например).
- Psh: показывает подробную информацию о дескрипторе определенного идентификатора процесса (например, дескрипторы объектов, сетевые подключения).
- Psw: показывает названия окон процессов для которых окна активны.
Все эти инструменты написаны на С как рефлективные DLL и могут быть рефлективно внедрены в порожденный процесс с помощью С2 фреймворка, такого как Cobalt Strike (или любого другого фреймворка, который поддерживает рефлективные DLL-инъекции). Для Cobalt Strike мы добавили скрипт-агрессор, который можно использовать для загрузки инструментов с помощью менеджера скриптов Cobalt Strike.
Давайте рассмотрим каждый конкретный инструмент, запущенный в Cobalt Strike, чтобы продемонстрировать функциональность и показать какую информацию можно собрать с его помощью:
Psx
Этот инструмент показывает подробный список всех процессов, запущенных в системе. Выходные данные можно сравнить с информацией на главном экране Process Explorer. Psx выводит имя процесса, его id, родительский PID, время создания и информацию, связанную с бинарными файлами процесса (архитектуру, название компании, версии и т.д.). Как вы видите, он также отображает кое-какую интересную информацию активного ядра системы, например, базовый адрес ядра, который полезен при эксплуатации ядра (например, для вычисления смещений ROP-гаджетов). Всю эту информацию можно собрать из обычного пользовательского контекста (без повышения прав).
Если у нас достаточно разрешений, чтобы открыть дескриптор процесса, можно прочитать дополнительную информацию, такую как контекст пользователя и уровень целостности его токена. Перечисление PEB и связанных структур позволяет получить информацию о пути образа и параметры командной строки:
Как вы могли заметить, мы читаем и выводим информацию о версии из бинарных образов процесса, например, название компании и описание. Зная название компании, можно легко перечислить все активные продукты безопасности в системе. С помощью этого инструмента мы сравниваем названия компаний всех активных процессов со списком известных поставщиков продуктов безопасности и выводим результаты:
Psk
Этот инструмент отражает информацию о работающем ядре, включая все загруженные модули драйверов. Как и инструмент Psx, он также предоставляет сводку обо всех загруженных модулях ядра от известных продуктов безопасности.
Psc
Этот инструмент использует те же методы для вывода информации об активных процессах, что и Psx, за исключением того, что он отображает только процессы с активным сетевым соединением (IPv4, IPv6 TCP, RDP, ICA):
Psm
Этот инструмент можно использовать для получения подробных сведений о конкретном процессе. Он будет отображать список всех модулей (DLL), используемых процессом и сетевым соединением:
Psh
То же самое, что и Psm, но вместо загруженных модулей, показывает список дескрипторов процесса:
Psw
Последний, но не менее важный инструмент Psw. Этот инструмент покажет список процессов с активными дескрипторами окон, тех, которые открыты на рабочем столе пользователя, включая заголовки окон. Это полезно для определения того, какие графические интерфейсы приложений открываются пользователем без необходимости создавать скриншоты рабочего стола:
Варианты использования
Вы можете задаться вопросом: «И как же это все поможет нам в операциях по наступлению?» После получения доступа к скомпрометированному активу мы обычно используем эту информацию для следующих целей:
- Обнаружить инструменты безопасности на скомпрометированном активе. Не только по информации о процессе, но и по загруженным модулям.
- Обнаружение пользовательских hook-engine’ов.
- Поиск возможностей для маневров (с помощью сетевых сеансов) и эскалации привилегий.
После первой компрометации вы можете периодически запрашивать подобную информацию о процессах и приступить к созданию триггеров. Например, мы автоматически вводим эту информацию в RedELK. Затем можно создать оповещения о подозрительных изменениях в информации о процессе, таких как:
- Запуск инструмента проверки безопасности или установка нового продукта end-point security.
- Входящие сетевые подключения из отдела обеспечения безопасности через RDP – сессию или удаленный PowerShell.
- Открытие дескриптора другим процессом на одном из наших вредоносных артефактов (например, файл, используемый для сохранения присутствия).
Заключение
В этой статье мы показали, как такие инструменты, как Sysinternals Process Explorer, можно использовать для получения подробной информации о процессах, запущенных в системе, и как эта информация может помочь администраторам и специалистам по безопасности устранять неполадки и проверять систему на наличие проблем с безопасностью или производительностью.
Эта же информация также актуальна и полезна для Red Team, которые имеют доступ к скомпрометированным системам во время работы. Она помогает лучше понять систему и IT-инфраструктуру вашей цели, а периодический опрос такой системы позволяет Red Team реагировать на возможные изменения среды (например, триггер расследования).
Мы реплицировали некоторые функциональные возможности, предоставляемые такими инструментами, как Process Explorer, поэтому мы можем использовать ту же информацию в наступательных операциях. Для этого были созданы несколько инструментов мониторинга процессов, которые могут быть использованы в рамках фреймворка С2, например Cobalt Strike. Мы показали, как пользоваться этими инструментами и какую информацию с помощью них можно собрать.
Эти инструменты доступны на нашей GitHub-странице и готовы к использованию в составе Cobalt Strike.
Узнать подробнее о курсе.
