10 правил SIEM, с которых надо начать
Наиболее универсальные и полезные правила, с которых стоит начать разработку детектирующего контента.
Никаких подключений в нерабочее время, никаких изменений парольной политики и прочего, что никак не позволяет поймать хакера в реальных условиях.
Подбор учетных данных
Множественные неудачные попытки входа в систему (Bruteforce) или использование одного пароля для множества учетных записей (Password Spraying).
Это одна из самых распространенных атак, так как злоумышленники часто пытаются получить доступ через слабые пароли.
И одно из самых интуитивно понятных правил.
ОС: Windows (Active Directory), Linux, приложения, облачные сервисы (AWS, Azure).
События: любые события авторизации, event ID 4625, Event ID 4624, syscall user_start, user_login
Логика: Подсчет неудачных попыток входа за короткий промежуток времени (например, 5 попыток за 1 минуту) с одного адреса.
Улучшения:
Добавить проверку на успешный вход после множества неудачных попыток. Поможет выявлять удачные попытки подбора и присваивать им приоритет выше.
Разделить отдельно на Bruteforce (одно учетрная запись) и Spraying (множество). Bruteforce может иногда генеировать False Positive, когда истек срок пароля сервисной учетной записи или пользователь после смены доменного пароля, забыл его поменять в почтовом клиенте.
Разделить по тима источников, приложений. По той же самой причине, некоторые приложения (например, почта) может иногда фозить.
RCE (Remote Code Execution)
Успешная эксплуатация уязвимостей, связанных с произвольным выполнением кода. RCE крайне опасная уязвимость. Можно пытаться создавать правила обнаружения под каждую отдельную новую уязвимость.
Я предлагаю создать универсальное, которое будет иметь чуть больше False Positive, но при этом будет способно алертить на сам факт исполнения кода, независимо от способа и конкретной уязвимости.
ОС: Windows, Linux.
События: старт процессов (Event ID 4688 / Sysmon 1, 11 / syscall execve, open, openat)
Логика: Обнаружение подозрительных запусков процессов от процессов веб-сервисов. Вроде w3wp.exe -> cmd.exe. Обнаружение выполнение команд от учетных записей веб-сервисов (www-data, apache, bitrix, teamcity, postgres). Для обнаружения Web-shell можно мониторить создание файлов процессами/учетными записями веб-сервисов. Файлов с интерпретируемыми расширениями: .php, .asp, .aspx и другие, в зависимости от языка приложения. Мониторить следует директории веб-приложений.
Улучшения:
Использовать белые списки (для некоторых приложений нормально выполнять некоторые действия/команды).
Разбить на 3 правила: последовательность процессов, сервисная учетная запись, потенциальное создание веб-шеллов.
Расширять список процессов, учетных записей и расширений файлов.
Фишинг
Фишинг — это основной вектор начального доступа для многих атак. Многие предлагают анализировать вложения (например, исполняемые файлы) и ссылки (подозрительные домены) - то есть логи почтового сервера.
Я предложу снова отталкиваться от логов операционной системы и анализировать процессы, ведь нам важен сам факт успешного запуска кода.
ОС: Windows.
События: старт процессов (Event ID 4688, Sysmon 1)
Логика: Анализирует запуск процессов из офисных программ, мессенджеров. winword.exe -> cmd.exe -> whoami.exe Тут могутиспользоваться как cmd.exe, powershell.exe, так и сразу макросом скачиваться файлы с внешних ресурсов и запускаться. Такой подход позволит обнаруживать вредоносные файлы, отправленные не только по корпоративной почте, но и с мессенджерах, но открытых на корпоративных устройствах.
Что пропустим: Фишинг - это не всегда офисные документы с макросами, иногда это защищенные паролем архивы и тогда прямой цепочки процессов может не быть. Атакующие могут направить ссылку на скачивание вредоносного исполняемого файла,что тоже разорвет логичную последовательность цепочки процессов. И есть еще известные методы, как даже с использование макроса разорвать цепочку. Так что правило не панацея, но опыт показывает, что может быть очень полезным.
Улучшения:
Регистрировать другие подозрительные действия от офисных программ: создание исполнямых файлов, например.
Повышение привилегий
Пока далеко не ушли от анализа последовательности процессов, иногда это еще и хороший способ обнаружить повышение привилегий. Он также не покрывает 100% ситуаций, потому что эксплоиты могут действовать по-разному и не предсказуемо. На то это и уязвимости, что они не прогнозируемы.
Что ловит: Запуск процессов с повышенными привилегиями (system).
ОС: Windows.
События: старт процессов (Event ID 4688, Sysmon 1)
Логика: Анализируем учетные записи, от которых запущен родитель и потомок. Если родитель запущен от пользовательской УЗ, а потомок уже в системной сессии - то это хороший индикатор того, что произошло повышение привилегий. И не важно это было повышение через уязвимость службы печати, JuicyPotato или манипуляция с токенами через именованные каналы.
Минусы:
Не поймает повышение привилегий, если нет прямого запуска дочернего процесса. Например, если повышение происходит через создание сервиса, то логика обнаружения будет уже другая.
DCSync
DCSync используется для кражи хэшей паролей из Active Directory. Для обнаружения атаки надо отслеживать попытки синхронизации данных домена (Event ID 4662) с использованием учетной записи с правами репликации.
ОС: Windows (Active Directory).
События: события репликации (Event ID 4662)
Улучшения:
Мониторинг изменений в группах с правами репликации.
Можно заватйлистить активность между известными контроллерами.
Living Off the Land
Использование встроенных инструментов ОС для выполнения вредоносных действий.
ОС: Windows, Linux.
События: старт процессов (Event ID 4688, Sysmon 1, syscall execve)
Известные хактулы
Очень простое правило, которое позволит обнаруживать использование инструментария для анализа защищенности. Не такое надежное, как изучать поведение каждой утилиты, но достаточно простое и показательное.
ОС: Windows, Linux.
События: старт процессов (Event ID 4688, Sysmon 1, syscall execve)
Логика: Собираем список инструментов: названия, метаданные (описание, компания), паттерны командной строки и алертим, если что-то из этого встречаем в событиях старта процессов.
Улучшения:
Разбить на типы (Hacktools, RAT и другие). Можно даже по типам инструментов.
Локальная разведка
После получения доступа злоумышленники часто проводят разведку, чтобы понять где они и с какими правами и дальше повышать свои привилегии и развивать атаку.
Что ловит: Использование команд для сбора информации (например,
whoami,ipconfig,ls).ОС: Windows, Linux.
События: старт процессов (Event ID 4688, Sysmon 1, syscall execve)
Логика: Анализ команд запускаемых процессов. Поискать на просторах интернета хорошие cheat sheet для Red Team и постараться покрыть все вариации, которые они могут использовать.
Улучшения:
Разбить правило на несколько, в зависимости от типа разведки: проверка прав, поиск директорий на запись, сбор информации о демонах/сервисах. Потому что разные виды разведки могут генерировать разное количество срабатываний, некоторые правила будут более точными.
Повышать критичность, если команды выполняются от подозрительной учетной записи.
Минусы:
Правила могут быть достаточно шумными и не указывать однозначно на компрометацию системы.
Подозрительные командлеты
Пока не ушли далеко от анализа командных строк, PowerShell часто используется для выполнения вредоносных команд. А в мире существует несколько известных фреймворков для анализа защищенности, которые используются атакующими, и при этом имеют специфичные командлеты, которые помогают их обнаружить.
PowerSploit, PowerView, PowerUp, Powershell Empire и другие.
ОС: Windows.
События: журнал Powershell (Event ID 4104, Event ID 4103)
Логика: Обнаружение выполнения командлетов, связанных с известными фреймворками и инструментами. Надо поресерчить просторы Github, собрать список таких командлетов и использовать их для обнаружения хакеров.
Улучшения:
Обнаркжение не только известных командлетов, но и подозрительных команд, таких как
Invoke-WebRequest,DownloadString.Обнаружение обфусцированных скриптов или Base64Encoded (
-EncodedCommand)
Что при этом надо помнить
Белые списки - ваш лучший друг. Если правило срабатывает 40 тысяч раз в сутки, то оно не сможет быть полезным для обнаружения хакера. Всегда важно проверять правило на реальном потоке событий и дорабатывать.
Ваша способность обнаружить хакера зависит не только от качества ваших правил обнаружение, но и от качества заведения источников в SIEM. Сложно обнаружить хакера там, откуда вы не получаете логи.
Это стартовый пак, необходимо постоянно улучшать ваши правила, комбинировать разные подходы: от очень точных, но узких правил до контекстных, но которые практически невозможно обойти.
Last updated