Lateral movement - тот этап, после которого компрометация почти перестаёт быть локальной проблемой. Пока атакующий держится в рамках одного хоста, инцидент ещё можно быстро изолировать. Как только начинается движение по соседним системам, цена ошибки растёт резко: появляются новые точки доступа, новые сессии, новые учётные данные и уже совсем другой масштаб последствий.
В Windows-среде это особенно чувствительно. Удалённое администрирование, сервисные учётки, SMB, WinRM, WMI, RDP, DCOM - всё это нужно инфраструктуре для нормальной работы, но всё это же регулярно используется и для горизонтального перемещения. Разница между штатной активностью и атакой здесь редко лежит на поверхности.
Именно поэтому lateral movement - одна из самых неудобных тем и для Red Team, и для Detection Engineering. Атакующему нужно пройти дальше тихо и без лишнего шума. Защитнику - увидеть не просто удалённый logon или запуск процесса, а связать это в осмысленную цепочку. В этой статье разберём обе стороны: как работают основные техники lateral movement в Windows и как их детектить по логам, артефактам и поведению.
Lateral Movement в Kill Chain
Lateral movement редко начинается с красивого удалённого выполнения на соседнем хосте. Обычно до него уже случается вполне приземлённая работа: первичный доступ, разведка среды, поиск учётных данных, понимание, куда вообще есть смысл двигаться дальше. Поэтому рассматривать lateral movement отдельно от остальной kill chain не очень полезно. В Windows он почти всегда стоит на стыке сразу нескольких этапов.Сначала атакующий должен понять, где он оказался. Рабочая станция, файловый сервер, jump host, терминальный узел, сервер приложений - это разные сценарии и разный потенциал для перемещения. Потом проверяются каналы: доступен ли SMB, отвечает ли WinRM, есть ли WMI/DCOM, жив ли RDP, можно ли удалённо создать сервис, есть ли на хосте активные сессии других пользователей. Только после этого выбирается техника. Не наоборот.
В этом и разница между аккуратным lateral movement и шумной вознёй по сети. Атакующий не использует всё подряд. Он смотрит, какой способ лучше ложится на уже полученный доступ. Если на руках NTLM-хэш локального администратора и открыт SMB - один маршрут. Если есть токен доменного пользователя и доступен WinRM - другой. Если на хосте уже сидит привилегированная интерактивная сессия, набор вариантов снова меняется.
MITRE ATT&CK TA0008: обзор техник
В MITRE ATT&CK lateral movement вынесен в тактику TA0008 - горизонтальное перемещение внутри среды после первичного закрепления.MITRE ATT&CK - это база знаний по тактикам и техникам атакующих, которую используют и offensive-, и defensive-команды для описания поведения в инфраструктуре.
В Windows-среде lateral movement почти никогда не сводится к одной технике. Обычно есть две части: сначала аутентификация на удалённой системе, потом выполнение действия на ней. Иногда это делает один инструмент, иногда - связка из нескольких. На практике всё собирается в довольно рабочий конструктор: PtH даёт аутентификацию, WMI или PsExec - исполнение, WinRM - удобный управляемый канал, RDP - уже полноценную интерактивную сессию.
Сегодня разберем такие техники:
| Техника | Что даёт атакующему |
|---|---|
| Pass-the-Hash | удалённую аутентификацию без знания пароля |
| WMI / DCOM | удалённый запуск процессов и работу через COM-объекты |
| PsExec / SMB | выполнение через создание сервиса и административные SMB-шары |
| RDP | интерактивный доступ или перехват существующей сессии |
| WinRM / PowerShell Remoting | штатное удалённое администрирование через PowerShell |
Артефакты - это следы активности в системе: события, процессы, соединения, сервисы, именованные каналы, временные файлы и другие наблюдаемые последствия выполнения техники.
PsExec, например, обычно заметнее на уровне сервисов и SMB, чем WinRM. WMI может выглядеть тише в интерактивном плане, но хорошо читается по журналам и по process lineage - цепочке родительских и дочерних процессов. RDP даёт полноценную сессию, но и поверхность для детекта у него своя: logon-события, терминальные журналы, новые сеансы, работа с
tscon, артефакты shadowing.Есть и ещё один момент, который постоянно всплывает в реальных инцидентах. Lateral movement почти никогда не идёт строго по одной линии. Атакующий может использовать PtH для доступа по SMB, затем через WMI или сервисное создание исполнить код, а уже потом перейти на WinRM или RDP, если это даёт более удобный контроль. То есть техники здесь не конкурируют. Они сцепляются и дополняют друг друга.
Предпосылки: какие credentials нужны
Не все учётные данные одинаково полезны для lateral movement. Наличие логина и пароля доменного пользователя ещё не означает, что можно спокойно ходить по соседним хостам. И наоборот - даже без знания пароля атакующий иногда уже имеет всё, что нужно для следующего шага.Полезно сразу разделять несколько сущностей:
- пароль - обычный секрет пользователя;
- NTLM-хэш - хэш пароля, который можно использовать в сценариях вроде Pass-the-Hash;
- Kerberos ticket - билет Kerberos-аутентификации для доступа к сервисам в домене;
- access token - объект в памяти Windows, который определяет, кем считается процесс и какие у него права.
Для lateral movement атакующему нужен не просто учётные данные, а данные, которые подходят для конкретного канала. Для Pass-the-Hash нужен NTLM-хэш учётной записи с административным доступом на целевой системе. Для WinRM обычно нужен логин и пароль или уже действующий доменный контекст с достаточными правами. Для RDP требуется интерактивный вход, а значит и соответствующая политика допуска. Для WMI, DCOM и PsExec почти всегда критичны локальные или доменные админские права на удалённом хосте.
На практике у атакующего обычно один из четырёх полезных сценариев. Либо это локальные админские учётные данные, переиспользуемые на нескольких машинах. Либо доменная учётка с широким административным доступом. Либо сессия привилегированного пользователя на уже скомпрометированном хосте. Либо сервисная учётка, у которой внезапно слишком много прав в сети.
Самая удобная ситуация для атакующего - когда в инфраструктуре повторяются локальные пароли администраторов или привилегированные доменные аккаунты логинятся на рабочие станции и серверы без жёсткой изоляции. Именно поэтому lateral movement так тесно связан с учетными данными: сначала нужно добыть материал, которым вообще можно аутентифицироваться дальше.
Но даже валидные учётные данные сами по себе ещё не гарантируют движение. Всё упирается в политику удалённого доступа и доступные протоколы. Не каждая учётка сможет зайти по RDP. Не каждый локальный админ сможет использовать WinRM, если тот отключён или ограничен. Не каждый сервисный аккаунт подойдёт для интерактивной сессии. Поэтому хороший lateral movement всегда учитывает не только набор полученных секретов, хэшей и токенов, - но и то, какой канал реально открыт между двумя узлами.
Для защитника это не менее важно. Ловить lateral movement, не понимая, какой тип учётных данных используется и через какой протокол идёт доступ, - почти всегда значит ловить слишком общий шум. Сетевой logon с NTLM по SMB, PowerShell Remoting через WinRM и интерактивная RDP-сессия на верхнем уровне могут выглядеть похоже. Но если копнуть чуть глубже, следы у них уже совсем разные.
Pass-the-Hash
Pass-the-Hash часто воспринимают слишком узко - как что-то из старых red team демонстраций, где с одним NTLM-хэшем бодро обходят половину сети. В реальной среде техника до сих пор работает, просто не существует отдельно от всего остального. Её успех всегда зависит от трёх вещей: где был получен хэш, есть ли у этой учётной записи административные права на целевом хосте и доступен ли канал, через который можно провести удалённую аутентификацию.Суть PtH довольно приземлённая. Атакующему не нужен сам пароль, если у него уже есть валидный NTLM-хэш и сервис, принимающий NTLM-аутентификацию. Windows в таком сценарии не различает, был ли этот хэш получен в ходе легитимного входа или извлечён из памяти, LSASS, SAM или другого источника. Если хэш валиден и учётная запись имеет нужные права, удалённый доступ сработает.
И вот здесь PtH становится реально опасной техникой. Она отлично цепляется за типовую Windows-инфраструктуру: локальные администраторы с одинаковыми паролями на нескольких машинах, привилегированные доменные аккаунты, которые логинились на серверы, сервисные учётки с неожиданно широким доступом. Один добытый хэш легко превращается в билет на следующий узел.
Механика Pass-the-Hash
Классический сценарий выглядит так: на уже скомпрометированной системе атакующий получает NTLM-хэш пользователя или локального администратора. Затем этот хэш используется для аутентификации к удалённому сервису - чаще всего через SMB, RPC, WMI или WinRM, в зависимости от инструмента и доступных в среде протоколов.Важно не смешивать PtH с NTLM relay.
NTLM relay - это пересылка NTLM-аутентификации другой системе без знания секрета.
Pass-the-Hash - это прямое использование уже полученного NTLM-хэша для входа от имени жертвы.
То есть в PtH атакующий уже владеет самим хэш-материалом и инициирует аутентификацию самостоятельно. В relay-сценарии он перехватывает и перенаправляет чужую попытку входа. Для lateral movement в Windows это важная разница: PtH - типовая техника посткомпрометационного перемещения, а не история про перехват трафика на входе.
На уровне протокола всё тоже без магии. Если удалённый сервис принимает NTLM и права учётной записи позволяют выполнить нужное действие, Windows пропустит запрос. Именно поэтому PtH так хорошо живёт в сценариях с SMB и удалённым управлением: инфраструктура уже содержит готовые механизмы аутентификации и выполнения действий, атакующему остаётся только подставить валидный контекст.
| Что есть у атакующего | Куда это обычно применяют | Что требуется на целевой системе |
|---|---|---|
| NTLM-хэш локального администратора | SMB, PsExec-подобные сценарии, WMI | одинаковая локальная учётка или локальные админские права |
| NTLM-хэш доменной учётной записи | SMB, WinRM, WMI, RPC | права этой учётки на удалённом хосте |
| NTLM-хэш сервисной учётной записи | доступ к узкому набору серверов или сервисов | настроенные права сервиса в конкретном сегменте |
| Хэш привилегированной учётки | почти любой удалённый административный канал | доступность протокола и отсутствие жёстких ограничений |
Инструменты: Mimikatz, Impacket, CrackMapExec
Для PtH обычно используются три класса инструментов: средства извлечения хэшей, средства удалённого выполнения и средства оркестрации.Mimikatz чаще фигурирует как инструмент для получения хэшей, токенов и билетов - из памяти Windows. Сам по себе он не является инструментом lateral movement, но часто становится первой точкой, где появляется материал для PtH.
Impacket - набор Python-инструментов для работы с сетевыми протоколами Windows. В контексте PtH он полезен тем, что даёт реалистичные сценарии удалённого выполнения через SMB, WMI и другие каналы без необходимости что-то вручную разворачивать на целевом хосте.
CrackMapExec, а теперь чаще его форки и родственные проекты, долгое время использовался как удобный оркестратор для массовой проверки доступа по SMB, WinRM и другим протоколам с использованием паролей и NTLM-хэшей.
В живом сценарии всё это выглядит не как одна команда, а как цепочка. Один инструмент помогает получить хэш, второй - быстро понять, куда с ним вообще можно зайти, третий - использовать найденный доступ для удалённого выполнения. Именно поэтому PtH редко смотрится как самостоятельная техника. Скорее это связующий слой между credential access и удалённым исполнением.
Что остаётся после PtH
Снаружи PtH не выглядит как отдельный магический тип логина. Для системы это обычно обычная NTLM-аутентификация по сети. Поэтому ловить технику по одному событию почти бесполезно. В логах защитник чаще видит не сам факт использования хэша, а последствия: тип логина, источник соединения, доступ к административным шарам, дальнейшее удалённое выполнение, создание сервиса или процесс, запущенный после сетевой аутентификации.Первый слой видимости - стандартные Windows Security Events. Для PtH особенно важен Event ID 4624 с Logon Type 3.
Logon Type 3 - это сетевой logon без интерактивного входа в локальную консоль. Но сам по себе
4624 / Type 3 не является детектом PtH. Такое событие встречается и в нормальной админской активности. Контекст появляется, если рядом видны:- NTLM-аутентификация там, где обычно ожидается Kerberos;
- вход от имени чувствительной учётной записи с нетипичного хоста;
- доступ к
ADMIN$,C$,IPC$; - последующее удалённое выполнение через SMB, WMI или сервисное создание;
- системные процессы и дочерние цепочки, которые появляются сразу после сетевого входа.
4672, а дальше начинается удалённая активность, это уже намного интереснее, чем просто очередной административный вход.На стороне Sysmon картина становится богаче. В дело обычно идут такие события:
| Sysmon Event ID | Что показывает | Зачем нужен в PtH-сценарии |
|---|---|---|
| 1 | создание процесса | увидеть удалённое выполнение после сетевого логина |
| 3 | сетевое соединение | зафиксировать SMB/RPC/WinRM-коммуникацию |
| 17 / 18 | создание и подключение к именованным каналам | поймать PsExec-подобные сценарии и IPC-следы |
| 11 | создание файла | увидеть dropper, временный сервисный бинарник, артефакты записи |
| 13 | изменение реестра | вспомогательные артефакты persistence или service config |
Detection: что реально ловить
Главная ошибка при детекте PtH - пытаться поймать сам хэш. В логах его не видно как отдельную сущность с подписью это был Pass-the-Hash. Видно совсем другое: NTLM-аутентификацию, нетипичный источник, привилегированную учётную запись, отсутствие интерактивной сессии и действие, которое последовало сразу после входа.Хорошая базовая гипотеза для охоты звучит так: привилегированная учётная запись выполняет сетевой NTLM-logon на хост, где раньше такой паттерн почти не встречался, после чего начинается удалённая активность.
Простой Sigma-шаблон для стартовой проверки выглядит +- так:
YAML:
title: Suspicious Network Logon With NTLM To Remote Host
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 3
AuthenticationPackageName: NTLM
condition: selection
level: mediumСильнее работает уже не одиночное событие, а корреляция:
| Что связывать | Почему это важно |
|---|---|
| 4624 Type 3 + NTLM | базовый сетевой вход |
| 4624 + 4672 | вход с привилегированным контекстом |
| 4624 + Sysmon 1 | после логина начинается удалённое выполнение |
| 4624 + доступ к ADMIN$/IPC$ | признак SMB-административной активности |
| 4624 + Sysmon 17/18 | возможный PsExec-подобный сценарий через named pipes |
Нормальная перспектива для защитника здесь такая: PtH - это не абстрактная техника из ATT&CK-матрицы, а комбинация сетевой аутентификации и последующего действия на удалённой системе. Если смотреть на неё именно под таким углом, детект становится заметно ближе к реальной атаке, а не к попытке угадать невозможную сигнатуру по одному событию.
WMI и DCOM
WMI и DCOM в lateral movement хороши тем, что выглядят как штатная удалённая работа Windows. Никакого отдельного “зловредного” канала тут не появляется. Атакующий использует механизмы, которые и так нужны администраторам, системам управления, скриптам автоматизации и части корпоративного ПО. Из-за этого техника часто переживает и обновления EDR, и базовые hardening-меры, если в инфраструктуре по-прежнему разрешено удалённое администрирование через эти интерфейсы.При этом WMI и DCOM не стоит смешивать в одну кашу. Они тесно связаны, но не идентичны. WMI (Windows Management Instrumentation) - это инфраструктура управления Windows, через которую можно получать информацию о системе и выполнять административные действия. DCOM (Distributed Component Object Model) - распределённый COM-механизм, через который многие из этих действий могут выполняться удалённо.
Для lateral movement это означает довольно простую вещь: если у атакующего есть подходящие права и канал не ограничен сегментацией или политиками, удалённое выполнение можно встроить в обычный административный трафик.
WMI: удалённое создание процесса
Самый известный сценарий с WMI - удалённый запуск процесса. Технически он выглядит довольно чисто: клиент подключается к удалённой системе, вызывает нужный WMI-класс и инициирует создание процесса без интерактивной сессии. В глазах ОС это не “эксплойт”, а нормальный вызов административного механизма.В offensive-практике WMI особенно любят за сочетание трёх качеств: техника не требует RDP, не зависит от создания отдельной консольной сессии и не шумит так явно, как сервисное выполнение через PsExec. Если на целевом хосте разрешён удалённый WMI и у учётной записи есть достаточные права, этого уже достаточно для движения дальше.
Типичный сценарий выглядит так: после успешной аутентификации на удалённой системе через WMI запускается
cmd.exe, powershell.exe или другой процесс, который уже делает следующий шаг, например, выполняет команду, запускает скрипт, собирает данные или тянет новый stage. И вот здесь часто возникает ловушка для защитника: само удалённое выполнение может выглядеть компактно и чисто, а вредная часть происходит уже внутри дочернего процесса.На стороне хоста это обычно проявляется через процесс
wmiprvse.exe.wmiprvse.exe - это WMI Provider Host, процесс Windows, внутри которого работают WMI-провайдеры и через который часто видна удалённая WMI-активность.
Если после сетевой аутентификации на системе внезапно появляется цепочка вроде:
wmiprvse.exe→cmd.exewmiprvse.exe→powershell.exewmiprvse.exe→ нестандартный бинарник из временной директории
DCOM abuse: MMC20, ShellWindows, ShellBrowserWindow
Если WMI - это наиболее известная административная поверхность, то DCOM abuse чуть менее очевиден и поэтому часто выглядит неприятнее. Атакующий использует удалённо доступные COM-объекты, чтобы выполнить действие на целевой машине, не прибегая к более ожидаемым сценариям вроде PsExec или PowerShell Remoting.Здесь регулярно всплывают объекты вроде:
| COM-объект | Что обычно используют |
|---|---|
| MMC20.Application | запуск команд через интерфейсы MMC |
| ShellWindows | доступ к shell-контексту и выполнению команд |
| ShellBrowserWindow | взаимодействие с оболочкой Windows |
На практике DCOM abuse обычно не используется в изоляции. Он хорошо ложится в цепочки, где у атакующего уже есть валидный контекст, но хочется выбрать менее ожидаемый путь выполнения. Например, после получения доступа на один хост и извлечения привилегированного контекста следующий узел может быть достигнут уже не через SMB или WinRM, а через DCOM-вызовы к COM-объектам.
В detection это особенно неприятно, потому что многие SOC-команды хорошо знают признаки PsExec и уже научились смотреть на
psexesvc, ADMIN$ и service creation. А вот удалённая COM-активность через mmc.exe, svchost.exe, dllhost.exe или shell-компоненты часто теряется в общей массе системных процессов, если нет нормального baseline.Что остаётся в логах и на хосте
Главная сложность WMI/DCOM в том, что детект здесь строится не на одном красивом артефакте, а на сочетании нескольких признаков. Удалённый вызов, сетевая аутентификация, родительский процесс, дочерний процесс, редкая цепочка запуска, иногда RPC/DCOM-сетевое взаимодействие - всё это вместе даёт картину. По отдельности почти каждый элемент может быть легитимным.Для WMI полезно смотреть как минимум на три слоя:
| Слой | Что искать |
|---|---|
| Security Log | удалённые логины и их источник |
| Sysmon | process creation и сетевую активность |
| WMI Activity Log | удалённые WMI-операции |
4624 с Logon Type 3, если доступ идёт по сети без интерактивной сессии. Дальше интереснее уже смотреть на то, что произошло после логина.В Sysmon главная опора - Event ID 1. Именно он покажет создание процессов после удалённого WMI-вызова. Если на сервере внезапно появляется
wmiprvse.exe, который рождает cmd.exe, powershell.exe, rundll32.exe или другой нетипичный дочерний процесс, это уже хорошая точка для расследования.Ещё полезен Microsoft-Windows-WMI-Activity/Operational.
Это журнал активности WMI, который при нормальной настройке может показывать удалённые вызовы, namespace и детали обращения. Он не всегда включён и не всегда удобно собран в SIEM, но если он есть - это один из самых ценных источников для разбора WMI lateral movement.
DCOM сложнее. Универсального одного события, которое скажет это был DCOM abuse, обычно нет. Приходится смотреть на косвенные признаки:
- нетипичный удалённый logon с последующим запуском системного процесса;
- создание процесса через
mmc.exe,dllhost.exe,svchost.exeили shell-компоненты; - RPC/DCOM-сетевое взаимодействие между узлами, которое не характерно для конкретной пары хостов;
- запуск дочернего процесса от имени процесса, который в этой роли обычно не выступает.
wmiprvse.exe будет слишком шумным. Но если на рабочих станциях такой паттерн почти не встречается, один-единственный запуск cmd.exe из-под wmiprvse.exe уже выглядит очень жирно.Detection: что реально работает
Для WMI хорошая рабочая гипотеза звучит так: на удалённой системе после сетевого логина появляется дочерний процесс отwmiprvse.exe, который нетипичен для данного хоста или выполняется от чувствительной учётной записи.Пример Sigma-шаблона под такой сценарий:
YAML:
title: Suspicious Process Spawned By WMI Provider Host
logsource:
product: windows
category: process_creation
detection:
selection:
ParentImage|endswith: '\wmiprvse.exe'
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\rundll32.exe'
condition: selection
level: highДля DCOM полезнее строить не одну сигнатуру, а набор слабых признаков:
- сетевой logon на хост;
- нетипичная RPC/DCOM-активность;
- запуск дочернего процесса от
mmc.exe,dllhost.exeили shell-процесса; - чувствительный аккаунт или необычный источник соединения.
mmc.exe, dllhost.exe, explorer.exe в серверном сегменте, wmiprvse.exe на рабочих станциях, где нет WMI-автоматизации, и так далее.PsExec и SMB
PsExec - одна из тех техник, которые знают вообще все: и атакующие, и админы, и SOC, и EDR. Из-за этого про неё часто думают слишком упрощённо. Либо как про шумную классику, которую давно все ловят. Либо как про удобный легитимный инструмент удалённого администрирования. На практике правда где-то посередине. Да, техника заметная. Да, она оставляет хорошие артефакты. Но если в среде по-прежнему открыт SMB, доступны административные шары и нет жёстких ограничений на удалённое создание сервисов, этот путь остаётся рабочим и в 2025 году.
Основная логика PsExec-подобного lateral movement очень прямолинейная. Атакующий аутентифицируется на удалённой системе с административными правами, пишет исполняемый компонент через SMB в административную шару, создаёт и запускает сервис, а дальше использует его как транспорт для команд и вывода. Это не самый тихий способ двигаться по сети, зато он надёжный, понятный и хорошо автоматизируется.
Именно поэтому рядом с оригинальным PsExec живёт целое семейство похожих сценариев:
smbexec, psexec.py, частично atexec, а в некоторых случаях и самописные вариации поверх Service Control Manager. Механика меняется в деталях, но суть одна: SMB даёт доступ к удалённой системе, а сервис или смежный системный механизм превращает этот доступ в выполнение кода.Создание сервиса и выполнение через SMB
Чтобы PsExec-сценарий вообще взлетел, атакующему обычно нужны две вещи: административный доступ к удалённому хосту и возможность работать с SMB-ресурсами вродеADMIN$ или IPC$. Дальше начинается довольно типовая последовательность.Сначала происходит аутентификация. Затем через SMB на целевой системе создаётся или копируется компонент, который будет запускаться удалённо. После этого через Service Control Manager создаётся сервис и запускается от имени
SYSTEM или другого привилегированного контекста.Service Control Manager - это подсистема Windows, управляющая системными службами. Через неё можно создавать, изменять, запускать и удалять сервисы локально или удалённо, если у учётной записи есть соответствующие права.
В классическом PsExec-стиле всё это часто завязано на сервисный бинарник и именованные каналы. Но даже если конкретный инструмент меняет имя файла, сервиса или паттерн записи, защитнику всё равно остаются знакомые куски: сетевой SMB-доступ, запись в административную шару, удалённое создание сервиса и запуск процесса под системным контекстом.
С offensive-стороны это удобно по нескольким причинам. Во-первых, такой сценарий стабильно работает в средах, где удалённое администрирование по SMB до сих пор считается нормой. Во-вторых, он почти не зависит от интерактивной сессии пользователя. В-третьих, результат предсказуем: если есть права и канал не закрыт, код на удалённой системе почти наверняка исполнится.
Но именно из-за своей прямолинейности PsExec-подобные техники хорошо читаются в телеметрии. Они оставляют больше шума, чем WMI или WinRM. Поэтому для Red Team это не всегда первый выбор, а для SOC - наоборот, одна из самых удобных точек наблюдения.
Именованные каналы и transport layer
Отдельный интерес в этой технике - named pipes, то есть именованные каналы.Named pipe - это механизм межпроцессного взаимодействия в Windows, который позволяет процессам обмениваться данными локально или по сети через именованный канал.
В PsExec-подобных сценариях именованные каналы часто используются как транспорт для передачи команд, стандартного вывода и ошибок. Это удобно: после запуска сервиса на удалённой системе атакующий получает рабочий канал общения с процессом, не поднимая что-то экзотическое поверх сети.
Для detection это большой плюс. В Sysmon события 17 и 18 как раз позволяют видеть создание и подключение к именованным каналам. И хотя named pipes используются легитимно очень часто, некоторые шаблоны выглядят достаточно характерно, особенно если они появляются в контексте сетевого логина, SMB-активности и сервисного запуска.
На практике полезно смотреть не только на факт существования pipe, а на полную цепочку:
- сетевой вход по SMB;
- доступ к
ADMIN$илиIPC$; - создание или запуск сервиса;
- появление pipe;
- запуск процесса от системного родителя или от сервиса.
Альтернативы: smbexec и atexec
Оригинальный PsExec - не единственный сценарий. В offensive-практике рядом с ним часто используютсяsmbexec и atexec. Они не идентичны, но решают похожую задачу: удалённо выполнить код на целевом хосте, используя уже имеющийся доступ.smbexec ближе по духу к PsExec, но в деталях работает иначе. Чаще он завязан на удалённое выполнение команд через сервисный механизм и SMB-доступ, но без необходимости тащить тот же сценарий, что у Sysinternals PsExec. Для защитника это означает, что имя артефакта может отличаться, а вот общая логика - сетевой вход, сервисная активность, выполнение команды, работа через админские шары - остаётся узнаваемой.atexec обычно использует механизм планировщика задач вместо сервисного запуска.Это уже не PsExec в чистом виде, но как альтернатива SMB-based remote execution встречается регулярно. Следы там немного другие: вместо service creation чаще всплывает task creation и соответствующие артефакты Task Scheduler.
Что остаётся в логах и на хосте
У PsExec-подобного lateral movement один из самых удобных профилей наблюдаемости. Если телеметрия в среде собрана более-менее вменяемо, техника почти всегда оставляет следы на нескольких уровнях сразу.Первый уровень - Windows Security Log. Тут важны всё те же сетевые входы, прежде всего:
| Event ID | Что показывает | Почему важно |
|---|---|---|
| 4624 | успешный logon | сетевой вход на удалённую систему |
| 4672 | специальные привилегии | вход от имени административной учётки |
| 5140 | доступ к сетевому ресурсу | обращение к SMB-шарам |
| 5145 | детальный доступ к шару | работа с ADMIN$, IPC$ и файлами внутри них |
5140 и 5145 особенно полезны, когда нужно понять, шёл ли доступ именно к административным SMB-шарам. Если после логина видно обращение к ADMIN$ или IPC$, а затем на системе появляется новый сервис или процесс - картина складывается быстро. Второй уровень - системные события сервисов. Для удалённого создания сервиса особенно важны события 7045 в System log. 7045 показывает установку нового сервиса. Для PsExec-подобных сценариев это один из самых ценных артефактов.Если на сервере внезапно устанавливается новый сервис с подозрительным именем, странным бинарным путём или коротким временем жизни, это уже отличный повод для расследования. Даже если инструмент маскирует имя сервиса, сам факт удалённого сервисного создания в неожиданный момент почти всегда остаётся видимым.
Третий уровень - Sysmon. Здесь особенно полезны:
| Sysmon Event ID | Что показывает | Где помогает |
|---|---|---|
| 1 | создание процесса | увидеть, что стартовало после сервиса |
| 3 | сетевое соединение | зафиксировать SMB-активность |
| 11 | создание файла | увидеть запись бинарника или вспомогательного файла |
| 17 / 18 | создание/подключение к named pipe | поймать транспорт через pipe |
| 13 | изменение реестра | сервисные и смежные следы в конфигурации |
Detection: на что лучше всего опираться
Хорошая гипотеза для PsExec/SMB lateral movement звучит довольно просто: на удалённой системе после сетевого SMB-доступа появляется новый сервис или нетипичный системный процесс, связанный с named pipe или выполнением команды.Пример Sigma-шаблона под установку подозрительного сервиса:
YAML:
title: Suspicious Service Installation For Remote Execution
logsource:
product: windows
service: system
detection:
selection:
EventID: 7045
condition: selection
level: highЕщё один полезный Sigma-подход - искать named pipe активность в сочетании с сервисным или системным контекстом:
YAML:
title: Suspicious Named Pipe Activity Related To Remote Service Execution
logsource:
product: windows
category: pipe_created
detection:
selection:
PipeName|contains:
- 'psexec'
- 'stdin'
- 'stdout'
- 'stderr'
condition: selection
level: mediumДля Splunk или ELK здесь хорошо работают вопросы не про сам инструмент, а про паттерн:
- какие хосты неожиданно начали устанавливать сервисы после сетевых логинов;
- кто обращается к
ADMIN$иIPC$, хотя обычно этим не занимается; - где появляются редкие named pipes сразу после удалённого входа;
- какие процессы стартуют от
services.exeв нетипичный момент и с нетипичным командным рядом.
RDP-техники
RDP в lateral movement всегда стоит чуть особняком. В отличие от WMI, PsExec или WinRM, здесь атакующий получает не просто удалённое выполнение, а полноценную интерактивную сессию. Это сразу меняет и удобство, и риск, и профиль детекта. Для атакующего RDP хорош тем, что позволяет работать в живой пользовательской среде: видеть рабочий стол, запускать инструменты руками, взаимодействовать с GUI-приложениями, использовать уже существующий контекст. Для защитника это тоже отдельная история, потому что артефакты RDP сильно отличаются от более “технических” каналов lateral movement.Но и здесь не всё сводится к обычному удалённому входу. В Windows-среде lateral movement через RDP - это не только новый logon по 3389. Сюда входят перехват уже существующей сессии, shadowing, переход через терминальные узлы, а иногда и туннелирование RDP через другой транспорт, чтобы обойти сетевые ограничения и упростить маршрут до нужного хоста.
RDP как интерактивный канал перемещения
Базовый сценарий понятен: у атакующего есть учётные данные, которым разрешён интерактивный удалённый вход, на целевом хосте открыт RDP, сетевой путь не заблокирован. После этого lateral movement превращается в обычную терминальную сессию.С offensive-стороны такой способ перемещения особенно удобен, когда нужно работать не только с консолью. Например, просмотреть интерфейс толстого клиента, открыть MMC-оснастку, зайти в GUI-инструменты администрирования, проверить, кто ещё залогинен на системе, достать артефакты из пользовательского профиля или руками пройти туда, где скриптовый доступ неудобен.
Но у RDP есть и минусы. Это заметнее.
Новая интерактивная сессия, logon-события, терминальные журналы, артефакты профиля, изменение состояния рабочего стола - всё это даёт защитнику гораздо больше материала, чем, например, один WMI-вызов.
Для lateral movement это означает довольно простую вещь: RDP редко становится самым тихим способом перемещения, но часто оказывается самым удобным, когда атакующему уже нужно не просто исполнить команду, а реально закрепиться на следующем узле и поработать в нём руками.
RDP Hijacking через tscon
Один из самых неприятных сценариев - не создание новой сессии, а перехват уже существующей. Здесь в игру входитtscon.tscon - это утилита Windows для подключения к существующей терминальной сессии или её переназначения. В административном контексте она используется легитимно, но при злоупотреблении позволяет переключиться на уже активную сессию другого пользователя.
С точки зрения lateral movement это удобно по двум причинам. Во-первых, можно не создавать новый RDP-logon и не оставлять лишнюю интерактивную сессию. Во-вторых, если на системе уже есть привилегированная сессия, атакующий получает гораздо более ценный результат, чем просто доступ под своей учёткой.
Типичный сценарий такой: атакующий уже имеет права на хосте, видит существующие RDP-сессии и использует
tscon, чтобы переподключиться к одной из них. В таком случае lateral movement выглядит уже не как сетевой вход с новой аутентификацией, а как переключение контекста внутри уже работающей системы.Для detection это важный сдвиг. Если SOC ждёт только новые RDP-логины, hijacking через
tscon может пройти заметно тише, особенно если процесс запускается локально на уже скомпрометированной машине и не создаёт нового удалённого logon-события на целевом узле.RDP Shadowing
RDP shadowing - ещё более интересный сценарий.Shadowing - это подключение к уже существующей RDP-сессии с возможностью наблюдать её или управлять ею.
Изначально это административная функция, полезная для поддержки и сопровождения. Но в посткомпрометационном сценарии она превращается в отличный механизм тихого присутствия. Атакующий может не создавать новую сессию и не перехватывать текущую в явном виде, а подключиться к уже существующей и работать через неё.
Для защитника эта техника неприятна тем, что она ближе к легитимному административному функционалу, чем к классическому lateral movement. Если в инфраструктуре действительно есть практика shadowing для helpdesk или админов, отличить злоупотребление от нормы становится заметно сложнее. Здесь уже мало одного события - нужен контекст: кто подключился, к чьей сессии, с какого хоста, было ли это типично для данной роли и данного времени.
С offensive-стороны shadowing особенно полезен там, где важно не шуметь новыми логинами и не ломать активную пользовательскую сессию. Атакующий просто встраивается в уже существующий терминальный контекст и получает доступ к тому, что там открыто.
Reverse tunneling и обход сетевых ограничений
Не всегда RDP доступен напрямую. В среде может быть сегментация, ACL, jump host’ы, ограничение по маршрутам, фильтрация между VLAN или отдельные правила только на вход с определённых узлов. В такой ситуации lateral movement через RDP часто дополняется туннелированием.Смысл довольно прямой: атакующий сначала закрепляется на одном узле, до которого уже есть доступ, а потом использует его как промежуточную точку для проброса RDP до следующего хоста. Это может быть SSH reverse tunnel, SOCKS-прокси, встроенный pivot через агент C2 или любой другой способ передать 3389 через уже имеющийся канал связи.
Для статьи важно не то, каким именно инструментом строится туннель, а то, что RDP в таких случаях становится вторым этапом lateral movement, а не первым. Сначала атакующий получает foothold на промежуточной машине, потом через неё открывает путь до целевой системы, куда напрямую с исходного узла бы не дошёл.
Foothold - это уже полученная точка присутствия атакующего внутри среды, с которой можно развивать дальнейшие действия.
Для detection это означает, что RDP-активность надо смотреть не в отрыве от инфраструктурного контекста. Иногда новый RDP-сеанс с неожиданного источника - это не просто странный logon. Это результат уже проведённого pivot внутри сети.
Что остаётся в логах и на хосте
У RDP хороший профиль наблюдаемости. Даже если не включать ничего экзотического, Windows оставляет довольно много следов: Security Log, терминальные журналы, события сеансов, следы интерактивного входа и действия в профиле пользователя.Базовый набор для анализа обычно такой:
| Источник | Что смотреть |
|---|---|
| Security Log | 4624, 4634, 4648, 4778, 4779 |
| TerminalServices журналы | события сеансов, переподключений и отключений |
| Sysmon | создание процессов после RDP-входа |
| Host artifacts | новые процессы, следы GUI-активности, изменения профиля |
Logon Type 10 - это удалённый интерактивный вход через терминальные службы, типичный для RDP.
Если на сервер или рабочую станцию внезапно приходит интерактивный вход по Type 10 от учётной записи, которая обычно туда не ходит, это уже хороший повод для расследования. Ещё полезны 4778 и 4779 - события переподключения и отключения сессии. Они особенно интересны в сценариях с reconnect, hijacking и нестандартной работой с терминальными сеансами.
На стороне Sysmon картина проще: RDP сам по себе не оставляет уникального process-артефакта lateral movement, как
wmiprvse.exe или services.exe в других техниках. Зато очень полезно смотреть, что произошло сразу после входа. Если после 4624 Type 10 на хосте появляются cmd.exe, powershell.exe, инструменты администрирования, архиваторы, сборщики артефактов или нестандартные бинарники, то интерактивная сессия быстро перестаёт выглядеть как просто удалённая работа администратора.Detection: что реально ловить
Для RDP хорошая базовая гипотеза звучит так: на хосте появляется удалённый интерактивный вход, который нехарактерен для данного пользователя, источника или временного окна, а после него начинается административная или подозрительная активность.Простейший Sigma-шаблон на новый RDP-logon может выглядеть так:
YAML:
title: Suspicious Remote Interactive Logon
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 10
condition: selection
level: medium- кто логинится.
- куда логинится.
- с какого хоста.
- в какое время.
- было ли это типично раньше.
- какие процессы появились после входа.
tscon и hijacking полезно смотреть на запуск самой утилиты и аномальную работу с терминальными сессиями. Если на хосте, где редко администрируют терминальные подключения руками, внезапно стартует tscon.exe, это уже очень хороший hunting-признак.Для shadowing всё сложнее. Тут полезнее искать комбинации:
- нестандартное подключение к существующей сессии.
- административная учётка, нехарактерная для поддержки.
- необычный источник.
- дальнейшая активность внутри уже существующего пользовательского контекста.
WinRM и PowerShell Remoting
WinRM в lateral movement любят за одну простую вещь: это штатный канал удалённого администрирования Windows, который во многих средах уже разрешён, предсказуем и не выглядит подозрительно сам по себе. В отличие от PsExec, тут нет обязательного сервисного шума. В отличие от RDP, не появляется новая интерактивная сессия с GUI. В отличие от части WMI-сценариев, PowerShell Remoting часто лучше вписывается в живые админские процессы. Именно поэтому при наличии подходящих прав WinRM становится очень удобным инструментом для тихого перемещения между узлами.
Для атакующего здесь важна не сама технология как таковая, а то, что она уже встроена в инфраструктуру. Если на хостах включён WinRM, если удалённый PowerShell не ограничен жёстко только jump host’ами, если у учётной записи есть право на удалённое управление, lateral movement начинает выглядеть почти как обычная работа администратора. И это делает технику особенно неприятной для detection.
Как выглядит злоупотребление WinRM
На практике WinRM чаще всего используется не как “эксплойт”, а как нормальный административный канал после получения подходящего контекста. У атакующего уже есть пароль, токен, доменная учётка или другой валидный доступ. Дальше он открывает удалённую PowerShell-сессию, исполняет команды, двигается по файловой системе, запускает процессы, проверяет окружение, разворачивает следующий stage или просто живёт на узле достаточно долго, чтобы собрать всё нужное.С offensive-стороны это удобно по нескольким причинам. Во-первых, нет необходимости создавать новый сервис, как в PsExec-подобных сценариях. Во-вторых, не нужен GUI, как в RDP. В-третьих, вся активность хорошо укладывается в нормальную модель удалённого администрирования Windows. Если в организации админы реально используют PowerShell Remoting, отличить злоупотребление от легитимной работы только по одному факту соединения уже сложно.
Есть и ещё одна причина, по которой WinRM любят. Он хорошо сочетается с post-exploitation. Сначала атакующий получает доступ на один хост, дальше извлекает более ценный контекст, а уже потом использует WinRM как удобный и относительно чистый транспорт для движения дальше. То есть здесь lateral movement выглядит не как отдельный фокус, а как естественное продолжение компрометации.
PowerShell Remoting как рабочий канал
PowerShell Remoting - это возможность удалённо выполнять PowerShell-команды и открывать сессии на других Windows-хостах через WinRM.Если смотреть на технику глазами защитника, здесь важно не путать два уровня. WinRM - это транспорт и инфраструктурный механизм. PowerShell Remoting - это уже то, как через этот транспорт исполняются команды и создаются удалённые сессии.
Для lateral movement это означает, что часть следов будет лежать в журналах аутентификации и WinRM, а часть - в PowerShell-артефактах. Именно поэтому одна только фиксация WinRM-соединения редко даёт полную картину. Нужно смотреть, что именно происходило после установления канала: какие команды шли, какие процессы запускались, какие дочерние цепочки появлялись на удалённом хосте.
На целевой системе это часто выглядит через процесс
wsmprovhost.exe.wsmprovhost.exe - это WinRM Provider Host, процесс, который часто появляется при удалённой PowerShell-сессии и служит хорошим индикатором того, что на хосте работает PowerShell Remoting.
Если после сетевого доступа на сервере появляется
wsmprovhost.exe, а затем уже из него или рядом с ним стартуют powershell.exe, cmd.exe, whoami.exe, ipconfig.exe, net.exe, nltest.exe или более специфичные инструменты, то перед защитником уже не просто удалённое управление, а вполне осмысленная post-exploitation активность.Constrained Language Mode и попытки обхода
В defensive-среде вокруг PowerShell давно появилась идея ограничивать его возможности через Constrained Language Mode.Constrained Language Mode - это режим PowerShell, в котором ограничивается использование части .NET, COM и других опасных возможностей, чтобы затруднить злоупотребление скриптовым окружением.
На бумаге это выглядит хорошо. Если PowerShell ограничен, часть post-exploitation сценариев реально становится неудобнее. Но lateral movement на этом не заканчивается. Во-первых, сам WinRM-канал никуда не исчезает. Во-вторых, атакующие регулярно ищут способы либо обойти CLM, либо увести выполнение в другой контекст: через .NET, через нестандартные загрузчики, через уже скомпилированные утилиты, через alternate execution paths.
Для статьи здесь важна одна мысль. CLM - полезная мера, но не серебряная пуля. В реальной среде lateral movement не упирается только в полнофункциональный PowerShell. Если удалённый доступ уже есть, атакующий почти всегда найдёт, чем работать дальше, особенно если на узле доступны дополнительные административные инструменты, интерпретаторы или обычные системные бинарники Windows.
Что остаётся в логах и на хосте
У WinRM и PowerShell Remoting очень удобный профиль наблюдаемости, если телеметрия в среде собрана нормально. Здесь можно смотреть сразу на несколько слоёв:| Источник | Что искать |
|---|---|
| Security Log | удалённые логины и их тип |
| WinRM журналы | факты удалённого управления |
| PowerShell журналы | выполнение команд и скриптов |
| Sysmon | процессы и сетевые соединения |
| Host artifacts | дочерние процессы и следы удалённой сессии |
На стороне WinRM полезно смотреть журналы Microsoft-Windows-WinRM/Operational. Они позволяют увидеть факты удалённого подключения, ошибки аутентификации, создание shell и другие детали удалённого управления. В зрелой среде это один из лучших источников для корреляции с последующей PowerShell-активностью.
На стороне PowerShell особенно ценны:
- Script Block Logging - если включён;
- Module Logging;
- PowerShell Operational Log;
- события запуска
wsmprovhost.exeи дочерних процессов.
Для Sysmon ключевым остаётся Event ID 1. Если на сервере стартует
wsmprovhost.exe, а затем появляются дочерние процессы, это уже очень хороший каркас для hunting. Ещё полезен Event ID 3, если нужно связать сетевое соединение с последующей активностью.Detection: что реально работает
Хорошая рабочая гипотеза для WinRM звучит так: на хосте появляется удалённая WinRM-сессия от нетипичного источника или чувствительной учётной записи, после чего черезwsmprovhost.exe или рядом с ним начинается командная активность.Простой Sigma-шаблон под процессный артефакт может выглядеть так:
YAML:
title: Suspicious PowerShell Remoting Host Activity
logsource:
product: windows
category: process_creation
detection:
selection:
Image|endswith: '\wsmprovhost.exe'
condition: selection
level: mediumБолее полезный подход - связывать несколько слоёв:
| Что связывать | Почему это важно |
|---|---|
| удалённый logon + WinRM Operational | подтвердить сам факт удалённого управления |
WinRM + wsmprovhost.exe | увидеть, что сессия перешла в исполнение |
wsmprovhost.exe + дочерние процессы | зафиксировать уже полезную активность |
| WinRM + PowerShell Script Block Logging | понять, что именно делал атакующий |
wsmprovhost.exe вообще появляется, хотя это не типично? Какие дочерние процессы стартуют после WinRM-сессий? Где удалённое PowerShell-управление идёт не с jump host’ов, а с рабочих станций или неожиданных серверов?У WinRM и PowerShell Remoting есть одна неприятная для защитника особенность. Эта техника выглядит почти слишком легитимно. Поэтому здесь особенно важно не цепляться за один процесс или одно событие, а смотреть на маршрут доступа целиком: кто пришёл, откуда, по какому каналу, что делал в сессии и насколько всё это похоже на нормальную административную жизнь среды.
Detection Engineering
Lateral movement почти никогда не ловится одной красивой сигнатурой. Это не тот случай, где достаточно увидеть один процесс и сразу закрыть инцидент. Слишком много техник используют легитимные механизмы Windows: сетевые логины, удалённые сессии, WMI, WinRM, сервисы, именованные каналы. Если смотреть на каждое событие отдельно, всё это легко спутать с обычной админской активностью.Рабочий detection здесь строится не вокруг магических IOC, а вокруг связок. Кто и откуда вошёл. По какому протоколу. Что произошло на целевом хосте сразу после логина. Какой процесс стал родителем. Был ли доступ к
ADMIN$, появился ли новый сервис, стартовал ли wmiprvse.exe, возник ли wsmprovhost.exe, пришёл ли интерактивный RDP-вход в нетипичное время. Чем лучше эта цепочка собрана, тем меньше шансов утонуть в шуме.Что собирать в первую очередь
Если телеметрия собрана поверхностно, lateral movement будет выглядеть как набор несвязанных мелочей. Поэтому сначала нужна нормальная база. Для Windows-среды минимально полезный набор выглядит так:| Источник | Ключевые события | Что дают |
|---|---|---|
| Security Log | 4624, 4672, 4634, 4648, 4778, 4779, 5140, 5145 | логины, привилегии, доступ к SMB-шарам, терминальные сессии |
| Sysmon | 1, 3, 11, 13, 17, 18 | процессы, соединения, файлы, реестр, named pipes |
| System Log | 7045 | установка нового сервиса |
| WMI-Activity | Operational events | удалённые WMI-операции |
| WinRM | Operational events | факты удалённого управления и shell activity |
| PowerShell | Operational, Script Block Logging | удалённое выполнение команд и скриптов |
Логика детекта по техникам
Удобнее всего смотреть lateral movement по паттернам, а не по названиям инструментов.| Техника | На что смотреть в первую очередь | Где лучше всего видно |
|---|---|---|
| Pass-the-Hash | 4624 Type 3 + NTLM + удалённая активность | Security Log, Sysmon |
| WMI | wmiprvse.exe как родитель дочернего процесса | Sysmon, WMI-Activity |
| DCOM | нетипичный системный родитель + RPC/DCOM-контекст | Sysmon, Security Log |
| PsExec / SMB | 5145 + 7045 + named pipes + services.exe | Security Log, System, Sysmon |
| RDP | 4624 Type 10 + 4778/4779 + процессы после входа | Security Log, TerminalServices, Sysmon |
| WinRM | WinRM Operational + wsmprovhost.exe + PowerShell | WinRM, PowerShell, Sysmon |
Sigma-правила: что реально полезно
Для lateral movement Sigma-правила хороши как стартовая точка. Они помогают быстро зафиксировать гипотезу и разложить базовый паттерн по SIEM. Но почти каждое правило из этой зоны требует адаптации под среду. Иначе либо утонешь в шуме, либо словишь пару красивых алертов и пропустишь всё остальное.Простой шаблон на подозрительный WMI execution уже был в предыдущей главе. Для WinRM и PsExec-цепочек можно держать что-то в таком духе.
Подозрительная установка сервиса:
YAML:
title: Suspicious Remote Service Installation
logsource:
product: windows
service: system
detection:
selection:
EventID: 7045
condition: selection
level: highwsmprovhost.exe:
YAML:
title: Suspicious Process Spawned Via WinRM
logsource:
product: windows
category: process_creation
detection:
selection:
ParentImage|endswith: '\wsmprovhost.exe'
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\net.exe'
- '\nltest.exe'
condition: selection
level: high
YAML:
title: Suspicious Remote Interactive Logon
logsource:
product: windows
service: security
detection:
selection:
EventID: 4624
LogonType: 10
condition: selection
level: medium4624 Type 3 → 5145 ADMIN$ → 7045 → Sysmon pipe events. Или WinRM Operational → wsmprovhost.exe → powershell.exe → net user.Baseline и корреляция
Самый полезный слой detection engineering для этой темы - baseline.Baseline - это модель нормального поведения среды: кто куда логинится, через какие протоколы, в какое время, с каких узлов, какие процессы обычно запускаются после удалённых сессий.
Без baseline lateral movement либо выглядит как хаос из тысяч событий, либо наоборот прячется внутри легитимного администрирования. С baseline картина меняется. Ты уже знаешь:
- какие хосты реально используют WinRM;
- какие админские учётки ходят по RDP;
- где
wmiprvse.exe- это норма, а где почти никогда не встречается; - где установка новых сервисов ожидаема, а где это ЧП;
- какие серверы обычно принимают NTLM, а где должен быть только Kerberos.
wsmprovhost.exe и его дочерних процессов, а также связь между SMB-доступом к ADMIN$, установкой сервиса и последующей активностью на целевой системе.Lateral movement редко выигрывают сигнатурой. Его выигрывают хорошей телеметрией, нормальной корреляцией и привычкой смотреть на инфраструктуру как на граф связей, а не как на набор отдельных хостов. Именно в этом виде detection engineering здесь работает лучше всего.
Что реально режет lateral movement
Полностью убрать риск горизонтального перемещения в Windows-среде не получится. Но есть меры, которые заметно ломают атакующему привычную механику и делают lateral movement либо дороже, либо шумнее, либо менее стабильным.Credential Guard полезен там, где задача - не дать атакующему легко вытаскивать данные аутентификации из памяти.
Credential Guard - это защитный механизм Windows, который изолирует чувствительные секреты и усложняет их кражу из LSASS.
Он не решает все проблемы сразу, но заметно бьёт по сценариям, где lateral movement строится на уже добытых хэшах, токенах и других данных аутентификации.
LAPS и Windows LAPS режут одну из самых неприятных предпосылок для PtH и перемещения через SMB - повторяющиеся локальные пароли администраторов. Если на десятках машин не живёт один и тот же локальный админский пароль, атакующему уже не так просто превратить один успешный компромисс в проход по соседним узлам.
Сегментация не убирает lateral movement как класс, но сильно сокращает число доступных маршрутов. Если между рабочими станциями, серверами, jump host’ами и административными зонами жёстко ограничены SMB, WinRM, WMI/DCOM и RDP, атакующему приходится либо искать более узкий путь, либо повышать уровень шума. Для защитника это уже хороший обмен.
Отдельно стоит PAW - Privileged Access Workstation, то есть выделенная рабочая станция для административной работы. Смысл здесь прямой: привилегированные учётки не должны жить на обычных пользовательских хостах. Чем меньше Domain Admin, серверный админ или чувствительная сервисная учётка логинится на случайные машины, тем меньше шанс, что lateral movement получит в руки действительно ценный контекст.
Если собрать всё в одну практическую модель, то самый заметный эффект дают не отдельные точечные меры, а их комбинация: защита данных аутентификации, уникальные локальные админские пароли, ограничение удалённых каналов и вынос привилегированного администрирования в отдельный контур. Именно это и бьёт по lateral movement сильнее всего, потому что ломает не один инструмент, а саму логику перемещения по среде.
Последний вопрос к защите
Lateral movement в Windows неприятен не потому, что техник слишком много. Неприятен он тем, что почти все они выглядят как что-то знакомое: удалённый логон, PowerShell-сессия, SMB-доступ, новый сервис, работа через штатный административный канал. По отдельности это обычная жизнь инфраструктуры. Проблема начинается в тот момент, когда эти действия складываются в маршрут и дают атакующему следующий узел, следующий контекст, следующий уровень контроля.И вот здесь остаётся вопрос, который для Windows-среды всегда звучит чуть тревожнее, чем кажется: если завтра в вашей сети начнётся lateral movement, что заметят раньше - саму технику или только её результат?
Последнее редактирование:
