Ловим горизонтальное перемещение через RPC на примере Impacket

Сложно ли обнаружить impacket? Да нет, он оставляет слишком специфичные артефакты в командной строке, а интернет полон ссылками с однотипными статьями и примерами вроде: 

%COMSPEC% /Q /c echo whoami ^> \\%COMPUTERNAME%\C$\__output 2^>^&1 > %SYSTEMROOT%\HziVFHQH.bat & %COMSPEC% /Q /c %SYSTEMROOT%\HziVFHQH.bat & del %SYSTEMROOT%\HziVFHQH.bat

Но на самом деле это классный пример, чтобы разобраться как работает RPC, и понять, что в этот момент происходит в системе и какие логи генерируются. Если почитать описание на github, то там сказало, что impacket - это не что иное как "коллекция классов python для низкоуровнего взаимодействия по некоторым протоколам (e.g. SMB1-3 and MSRPC)".

PSExec

Impacket's psexec.py — это аналог классического PsExec от Sysinternals. На самом деле у классического инструмента существует множество аналогов:

  • CSExec - A C Sharp psexec implementation

  • PAExec

  • модуль metasploit и т.д.

Но работают они все примерно по одному принципу:

1. Копирование исполняемого файла

  • Загружает на удалённую систему временный исполняемый файл (PSEXESVC.exe в классической реализации) в:

    • ADMIN$ (если есть права администратора) → C:\Windows\

Реализация psexec metaspolit/impacket использует рандомно сгенерированные имена службы и исполняемого файла. Impacket позволяет задать произвольное имя сервиса через ключи запуска утилиты.

  • В этот момент регистрируется несколько событий Event ID 5145: проверка прав на запись, непосредственно сама запись, проверка успешности и т.д. Происходит это в отдельной сессии. Запись исполняемого файла происходит самой первой, раньше, чем доступ к RPC.

  • Зарегистрируется Sysmon 11 (создание файла), создателем в данном случае будет процесс System с PID 4 (ядро Windows).

Всегда, когда файл создается через SMB, его создателем в событии Sysmon 11 выступает system (4). Говорит о том, что можно смело искать Event ID 5145, чтобы понять под какой учетной записью и с какого узла был создан тот или иной файл.

2. Поключение к RPC для получения номера порта службы

  • В данном случае интересует svcctl - это Service Control Manager Remote Protocol, часть RPC (Remote Procedure Call) в Windows, которая позволяет управлять службами (сервисами) удалённо или локально.

  • Клиент подключается к порту 135, чтобы узнать динамический порт службы svcctl. В этот момент можно увидеть сетевое соединение с атакующего узла на порт 135 атакуемого узла. Соединение примет процесс svchost.exe, и sysmon 3 в DestinationPortName зарегистрирует значение "epmap"

// Sysmon 3
"SourcePort": 54042              # чуть позже расскажу, зачем это тут
"DestinationPort": 135
"DestinationPortName": "epmap"
"Initiated": "false"             # соединение входящее
"Image": "C:\\Windows\\System32\\svchost.exe"

  • RPC Endpoint Mapper (EPM) возвращает текущий динамический порт, на котором работает svcctl.

  • Клиент в последствии подключается напрямую к этому порту и выполняет операции (запуск, остановку и т. д.) - пункт 4

3. Аутентификация

  • Impacket psexec подключается к удалённому хосту с использованием:

    • Логина и пароля (user:password).

    • Хэша NTLM (user:NTLM_hash) — Pass-the-Hash.

    • Kerberos-билета (если настроена аутентификация через Active Directory).

  • В этот момент регистрируется событие 4624. "IpPort" (исхоядщий) будет уже 54043 (увеличится на единицу). В этом событии видно6 под какой учетной запись подключились и какая сессия в итоге была создана на атакуемом узле.

В Windows динамические порты (для исходящих соединений) выделяются из диапазона 49152–65535, увеличиваясь на единицу для каждого нового соединения. Для приема входящих соединений обычно используются фиксированные порты (обычно ниже 49152), зарегистрированные или системные (например, 80 для HTTP, 443 для HTTPS).

Это поведение определяется стандартом RFC 6335 и настройками Windows (можно изменить через реестр или netsh).

4. Создание и запуск службы

  • Через Service Control Manager (SCM) создание службы с именем вроде PSEXESVC-XXXXX. (В случае impacket будет случайное имя службы)

  • В параметрах службы указывает путь к загруженному ранее файлу. В случае impacket имя файла будет совпадать в именем службы, в случае с psexec metasploit - не будут.

  • Зарегистрируется несколько событий:

    • Event ID 5145, где в RelativeTargetName будет значение svcctl.

    • Sysmon 3 (или Event ID 5156), также на входящее соединение, порты как исходящий так и входящий будут оба уже из динамического диапазона. Принимать соединение будет процесс services.exe

    • Event ID 7045 или Event ID 4697 - события создания/изменения службы Windows. В Event ID 4697 ClientProcessId = 0 и ParentProcessId = 0, это является индикатором создания службы через RCP.

Так как использование impacket предполагает создание служб/запланированных задач, то для его работы необходим права локального администратора.

5. Запуск службы, которая открывает именованный канал (named pipe) для взаимодействия.

  • Запустится процесс из ранее созданного файла, родителем его будет services.exe. (Event ID 4688, Sysmon 1). Так как процесс запускается как сервис, все действия выполняются от имени NT AUTHORITY\SYSTEM, то есть с максимальными привилегиями в системе.

  • Этот процесс создаст именованные каналы для приема команд и вывода результатов.

  • В этот момент регистрируются Sysmon 17 и 18. В случае с классическим PSexec, каналы будут иметь специфичный префикс PSEXESVC- .

6. Очистка

  • Останавливает и удаляет службу.

  • Удаляет временный файл (если не задан ключ --no-cleanup).

Что ловим

  1. Event ID 5145 и обращение в svcctl

  2. EventID 4697, где в ClientProcessId = 0 и ParentProcessId = 0

  3. Не очень надежно, но создание службы (Event ID 7045, 4697), файла (Sysmon 11) и именованных каналов (Sysmon 17, 18) с артефактом psexe*

SMBExec

  1. Аутентификация

    • smbexec подключается к удалённому хосту по протоколу SMB, используя переданные учётные данные (логин, пароль, хэш NTLM или Kerberos-билет). Точно также, имея пароль/хеш/билет пользователя с правами локального администратора.

  2. Создание службы

    • Утилита создаёт временную службу Windows (BTOBTO — захардкоженное имя, но может быть изменено) через svcctl (Service Control Manager).

    • В качестве исполняемого файла службы указывается cmd.exe /c <команда>. SMBExec уже не создает исполняемый файл, то есть не оставляет событие Sysmon 11.

  3. Выполнение команды

    • Служба запускается, выполняя переданную команду.

    • Вывод команды записывается в файл на общей папке ADMIN$ (например, C$\Windows\Temp\<random>.txt).

    • Учитывая все выше и случает очень специфичный cmdline с перенаправлением вывода как при создании службы. Так и при последующем создании процесса. %COMSPEC% /Q /c echo whoami ^> \%COMPUTERNAME%\C$__output 2^>^&1 > %SYSTEMROOT%\UmxbEYht.bat & %COMSPEC% /Q /c %SYSTEMROOT%\UmxbEYht.bat & del %SYSTEMROOT%\UmxbEYht.bat

Значения в %% - это перемнные окружения, которые при выполнении службы заменятся настоящими: %COMSPEC% - > cmd.exe %SYSTEMROOT% - c:\windows %COMPUTERNAME% - имя текущего узла

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

  1. Чтение вывода

    smbexec читает результат из созданного файла через SMB. Еще раз регистрируется Event ID 5145.

  2. Очистка

    Служба удаляется, временные файлы стираются.

Из особенностей, smbexec запускается не интерактивно, поэтому на каждую команду будет создаваться отдельный сервис, который будет быстро удаляться.

Что ловим

  • Также обращения к svcctl.

  • Для событий создания служб и процессов ищем паттерны перенаправления вывода.

  • Создание и быстрое удаление служб.

  • Можно поискать установку службы Event ID 7045 и именем BTOBTO, но это не очень надежно. А также execute.bat и %COMSPEC% в ImagePath.

ATExec

Этот инструмент для выполнения команд на удалённом Windows-хосте через Task Scheduler (планировщик заданий), также используя протокол DCE/RPC поверх SMB.

В целом принцип работы почти идентичный, только вместо svcctl использует atsvc - ловим доступ к нему. Кстати, в корпоративных инфраструктурах довольно хороший индикатор, который практически не фолзит, в отличие от доступа к svcctl.

Вместо службы создает запланированную задачу, поэтому отлавливаем Event ID 4698. Тут аналогично ClientProcessId = 0 и ParentProcessId = 0.

И еще для запланированных задач регистрируется событие Event ID 129 (это журнал самого планировщика) - запуск процесса из запланированной задачи. То есть можно однозначно связать созданную задачу и запущенный из не процесс Event ID 4698 -> 129 -> 4688. Родителем запущенного процесса в Event ID 4688 будет svchost.exe/taskeng.exe.

WMIExec

WMIExec использует протокол DCE/RPC и WMI для выполнения команд на удалённом компьютере под управлением Windows.

В целом все тоже аналогично. Для выполнения команд запускает cmd.exe (или другую команду) через Win32_Process. В этом случае родителем процесса будет процесс wmiprvse.exe.

Так как не использует ни службы, ни задачи, команды выполянютяс в той же сессии и от имени того же пользователя, который обращался к RPC. Номер сессии позволяет связать Event ID 4624 и Event ID 4688, такая связка покажет кто, откуда подключился, и какие действия выполнил.

Строка заупска процесса имеет вид: cmd.exe /Q /C 1> \\127.0.0.1\ADMIN$__<EPOCHTIME> 2>&1

Ах да, Event ID 5145 не регистрируется.

Что почитать

А лучше взять impacket, позапускать и посмотреть на артефакты. А еще посмотреть на код и на захаркоженные значения, что может стать IoA.

PreviousSMB: Атаки через RPC и именованные каналыNextОхотимся на GetSystem: повышение привилегий через именованные каналы

Last updated

Was this helpful?