23.07.2020 10:06:27 |
Автор: 
Кадр из мультфильма Жил-был пес
Итак, стандартных средств мониторинга становится недостаточно. Этому способствуют несколько факторов:
индикаторы компрометации (хеши, IP-адреса и доменные имена) часто бывают одноразовыми, так как их изменение не представляет труда для злоумышленника, особенно в случае с APT;
атакующие применяют в работе легитимные исполняемые файлы, штатные средства ОС и т. д.;
для перемещения по сети в большинстве случаев используются не эксплойты, а украденные легитимные учетные данные;
на практике часто встречается ВПО, которое не детектируется ни антивирусом, ни сетевыми сигнатурами;
с ростом инфраструктуры становится проблематично вовремя обновлять сигнатуры и лицензии.
Даже при успешном выявлении атаки у вас будет недостаточно информации, чтобы однозначно ответить на вопрос: исчерпан текущий инцидент или необходимы еще какие-либо меры. Ведь множество событий попросту не отслеживается: работа с реестром, создание файлов, загрузка модулей в память, командная строка созданного процесса и так далее.
Мониторинг конечных точек существенно расширяет возможности по выявлению и предотвращению атак: он позволяет перейти от детектирования хешей, IP и доменов к детектированию хостовых артефактов, инструментов и TTP (да-да, той самой пирамиды боли).
Несколько примеров техник, которые часто встречаются на практике и не детектируются без хостового мониторинга:
DLL Hijacking
Living off the land
Использование Mimikatz
Дополнительный мониторинг конечных точек можно организовать с помощью встроенных в ОС средств (расширенный аудит), бесплатных утилит (например, Sysmon) и коммерческих решений (продукты класса EDR). Рассмотрим, какие достоинства и недостатки имеют эти подходы на примерах детектирования различных вариаций упомянутых выше техник.
Расширенный аудит. Windows Event Logging
О встроенном аудите знают все. Как показывает практика, включив один лишь сбор событий создания процесса вместе с командной строкой, вы существенно облегчите процесс мониторинга и расследования инцидентов (закон Парето в действии).
При грамотной настройке мы закрываем некоторые пробелы стандартного подхода и видим:
факты запуска процессов вместе с командной строкой;
запускаемые PowerShell-скрипты в декодированном виде (Script block logging);
частично работу с файлами и реестром;
активность, связанную с учетными записями (создание/удаление пользователей и так далее).
У нас появляется возможность детектировать новые техники:
некоторые варианты DLL hijacking по созданию файлов с определенными путями;
использование LOLBin и Mimikatz по паттернам в командной строке.
При этом у злоумышленника все еще есть возможность избежать обнаружения. В случае с LOLBin это может быть копирование файла в другую папку под другим именем и обфусцирование командной строки. А Mimikatz можно перекомпилировать с измененными командами и строками, что не позволит обнаруживать его использование по командной строке. Также не будут видны варианты, когда на машину помещается легитимный бинарный файл, подверженный DLL hijacking.
Код Mimikatz с измененными строками
Настроить аудит Windows можно на любой системе без предустановки стороннего ПО, но есть и существенные недостатки:
1. Неудобная и плохо масштабируемая настройка.
Пример: чтобы поставить на мониторинг определенную ветку реестра, для нее нужно отдельно настроить ACL. Сам факт того, что нужно проводить какие-то действия, на практике выливается в проблемы и задержки по времени, особенно в случае крупных инфраструктур. Если это делается для расширения мониторинга (например, для детектирования какого-нибудь способа UAC Bypass), то время не играет критической роли. Но если такая необходимость возникает во время инцидента, это затрудняет процесс реагирования.
2. Отсутствие контроля.
Если события перестанут регистрироваться или поступать в используемые системы мониторинга, вовремя понять это, скорее всего, не получится, так как нет централизации.
3. Простота противодействия.
Даже злоумышленники с низкой квалификацией знают, как скрываться от стандартного аудита. Вопрос только в том, насколько эффективно и незаметно они это сделают.
Примеры техник:
Обычная очистка логов. Вероятность удачного восстановления событий зависит от того, сколько времени прошло с момента очистки.
Приостановка потоков службы аудита с последующим выполнением вредоносных действий или удалением событий (например, с помощью инструмента github.com/QAX-A-Team/EventCleaner).
Сокрытие событий с помощью нарушения структуры соответствующего файла .evtx (http://personeltest.ru/aways/github.com/fox-it/danderspritz-evtx).
Временное перенаправление событий в отдельный файл. О такой технике мы писали в предыдущей статье.
4. Сама по себе настройка аудита не даст возможности организовать мониторинг. Для начала придется наладить централизованный сбор событий, а потом использовать дополнительные инструменты, например, SIEM, для их анализа.
5. Низкая информативность событий. Отсутствует возможность получать хэш запускаемого процесса, отслеживать загрузку библиотек в память процессов и так далее.
Сходство Sysmon и EDR
Sysmon не является полноценным EDR-решением, так как в нем нет возможности выполнять активные действия на системе. Но механизм сбора событий точно такой же, как и в коммерческих EDR: работает он на двух технологиях обратных вызовах ядра и ETW. Подробно описывать их не будем рассмотрим только, как появляются события и кто инициатор их создания.
Обратные вызовы ядра. Например, PcreateProcessNotifyRoutine, PcreateThreadNotifyRoutine.
Где и как вызываются эти и другие обратные вызовы, можно увидеть в соответствующих функциях ядра. Пример вызова callbackов при создании процесса приведен ниже:
Цикл вызова callbackов в CreateProcessW -> NtCreateUserProcess -> PspInsertThread.
То есть вызывает эти callbackи поток родительского процесса, вызвавший CreateProcess.
Event Tracing Windows (ETW).
В части появления событий ETW работает похожим образом. Снова рассмотрим пример с созданием процесса. При вызове CreateProcessW поток родительского процесса выполняет следующие действия (упрощенная схема):
CreateProcessW (kernel32.dll)
NtCreateUserProcess (ntdll.dll, переход в режим ядра)
NtCreateUserProcess (ntoskrnl.exe, далее работа в режиме ядра)
PspInsertThread (здесь вызываются и callbackи)
EtwTraceProcess
EtwpPsProvTraceProcess
EtwWrite
Таким образом, поток родительского процесса является прямым инициатором создания события ETW. Примерно таким же образом работает запись остальных событий, например, сетевых. Ниже приведен пример создания событий, связанных с сетевой активностью:
Функция ядра EtwpNetProvTraceNetwork
Из всего вышесказанного следует два вывода:
1) И Sysmon, и EDR использует для сбора событий только встроенные возможности Windows, что обеспечивает надежность работы.
2) Злоумышленник может использовать методы сокрытия, которые будут применимы и к Sysmon, и к EDR. Обратные вызовы ядра можно снять в памяти ядра с помощью подписанного драйвера. А зная описанный механизм регистрации событий, можно понять, почему Sysmon и некоторые EDR не могут обнаружить определенные техники инжектирования в процесс (например, с помощью APC) или PPID spoofing.
Sysmon
Использование Sysmon позволяет расширить возможности стандартного аудита. События при этом записываются в отдельный журнал. Некоторые примеры информации, которой нет в аудите Windows, но есть в Sysmon:
более подробная информация о запускаемых исполняемых файлах (хеш, оригинальное имя, цифровая подпись и так далее);
загрузка драйверов и библиотек;
изменение статуса сервиса Sysmon;
создание потока в другом процессе;
доступ к процессу;
хеши файлов, создаваемых в альтернативных потоках данных;
создание пайпов.
Преимущества мониторинга описанных выше процессов очевидны (в публичном доступе есть множество правил и статей на тему детектирования различных техник). Плюс появляется возможность детектировать новые вариации известных техник:
1) копирование LOLBin под другим именем можно выявлять по соответствию полей OriginalFileName, Image и Hashes из события создания процесса;
2) можно детектировать загрузку неподписанных библиотек, что в некоторых случаях позволяет обнаружить DLL hijacking;
3) есть потенциальная возможность выявлять Mimikatz с помощью вышеупомянутых методов или по событию ProcessAccess к процессу lsass.exe.
Настройка аудита осуществляется с помощью конфигурационного файла, что в случае с созданием файлов и событиями реестра намного удобнее настройки ACL.
При этом нужно учитывать следующие моменты:
Необходимость дополнительных инструментов. Так как события пишутся в журнал, то, как и в случае с расширенным аудитом Windows, Sysmon нужно использовать в связке с другими инструментами, например, SIEM.
Плохое масштабирование и управляемость. В крупных инфраструктурах возникают проблемы с обновлением и учетом текущих версий конфигурационных файлов, так как Sysmon не предоставляет возможность централизованного управления. Для мониторинга корректной работы сервиса необходимы дополнительные инструменты.
Как и в случае с расширенным аудитом, отсутствие событий по тем или иным причинам не удастся вовремя обнаружить.
Внимание со стороны ИБ-сообщества. Так как утилита является бесплатной и общедоступной, сообщество уделяет ей большое внимание. В открытом доступе есть различные варианты конфигурационных файлов, множество правил для Sysmon и тематических статей. Такое внимание работает и в обратную сторону: известны слабые места утилиты, и опытный злоумышленник знает, как остаться незамеченным.
Про способы обхода некоторых возможностей Sysmon можно почитать здесь, здесь и здесь.
Endpoint Detection & Response
С ростом размера и критичности инфраструктуры недостатки Sysmon становятся существенными. Качественные EDR имеют несколько преимуществ (специфические для конкретных продуктов возможности описывать не будем):
1) Расширенный набор регистрируемых событий
Здесь все зависит от конкретного продукта. Например, встречается логирование всего интерактивного ввода в командную строку, что позволяет детектировать техники, которые не видно ни с аудитом Windows, ни с Sysmon.
Здесь стоит описать вариант использования Mimikatz, который мы наблюдали во время одного из расследований. Есть исполняемый файл, который содержит зашифрованный Mimikatz в ресурсах. При передаче в командной строке верного пароля и вектора инициализации Mimikatz расшифровывается удачно и принимает команды в интерактивной командной строке. При этом в событиях создания процесса не появляется никаких команд.
Логирование интерактивного ввода, в свою очередь, поможет детектировать такой случай, если Mimikatz не будет перекомпилирован (в нашем случае строки остались нетронутыми).
2) Централизованное управление и настройка
В большой инфраструктуре возможность централизованной проверки состояния и изменения настроек агента играет критическую роль. Без нее реагирование может затягиваться на часы, а то и на дни.
3) Самодостаточность
В большинстве случаев EDR это самостоятельный продукт со своим интерфейсом, который может использоваться не только в связке с другими инструментами, но и отдельно.
Может присутствовать возможность писать собственные правила детектирования. Так как набор доступных данных больше, чем у расширенного аудита или Sysmon, у аналитиков появляется больше возможностей для детектирования различных паттернов атак.
4) Возможность активного реагирования
Во время реагирования на инцидент необходимость выполнить какие-либо действия на множестве систем практически всегда становится проблемой.
EDR позволяет в удобной интерактивной форме выполнять множество действий:
работать с файлами и реестром
блокировать сетевые соединения
завершать процессы
сканировать yara-правилами
собирать артефакты для последующего анализа (например, образ памяти)
автоматизация всего вышеуказанного в той или иной степени
и многое другое.
Так как класс продуктов EDR изначально создавался для обеспечения хостового мониторинга и реагирования, недостатков у таких решений в этой области существенно меньше. Здесь все зависит от возможностей конкретного продукта. Не обходится и без слепых зон, например, отсутствует возможность углубленного анализа сетевой активности (проблема, которая успешно решается продуктами NTA/NDR).
Практика показывает, что наличие EDR в инфраструктуре существенно расширяет возможности по выявлению угроз, а также ускоряет реагирование и облегчает расследование инцидентов, позволяя более точно восстанавливать хронологию событий. Sysmon выступает в качестве полумеры, а в случае с одним только стандартным аудитом, который легко обойти, приходится довольствоваться менее информативными артефактами, в том числе необычными, о которых мы писали в предыдущей статье.
Автор: Аскер Джамирзе, старший инженер технического расследования отдела расследования инцидентов JSOC CERT
Категории: 
Реализация алгоритма MurMurHash2
Функция, осуществляющая разбор конфигурационного
файла
