Elastic Security стремится превзойти противников в инновациях и обеспечить защиту от новейших технологий злоумышленников. В Elastic Security 8.8 они добавили новые средства обнаружения на основе стека вызовов ядра, которые повышают эффективность борьбы с угрозами в памяти. В данной статье мы разберем Как обнаружить угрозы в памяти.
Глубокая видимость
Новая возможность обнаружения на основе стека вызовов использует нашу существующую глубокую встроенную видимость ядра для наиболее распространенного поведения системы (процесс, файл, реестр, библиотека и т. д.). С каждым событием мы захватываем стек вызовов для данного действия. Позже к ним добавляется информация о модуле, символы и свидетельства подозрительной активности. Это дает нам видимость, подобную procmon, в режиме реального времени, обеспечивая расширенные возможности предотвращения торговли в памяти.
Поля стека вызовов создания процесса:
Поля стека вызовов файла, реестра и библиотеки:
Новые правила
Дополнительная видимость не поднимет планку, если мы не сможем соединить ее с настроенными и высоконадежными средствами предотвращения. В версии 8.8 встроенная защита поведения включает более 30 правил, обеспечивающих высокую эффективность против передовых методов злоумышленников, таких как: — Прямые системные вызовы — Уклонение на основе обратных вызовов — Преодоление модулей — Загрузка библиотеки из неподдерживаемой области — Процесс, созданный из неподдерживаемой области регион — многое другое
Стеки вызовов — это мощный источник данных, который также можно использовать для улучшения защиты от угроз, не связанных с памятью. Например, следующие запросы EQL ищут создание дочернего процесса или расширения исполняемого файла из процесса Office со стеком вызовов, содержащим VBE7.dll (явный признак наличия документа с поддержкой макросов). Это увеличивает сигнал и охват логики правил, одновременно сокращая необходимые усилия по настройке по сравнению с событиями простого создания процесса или файла без информации о стеке вызовов:
Ниже приведены несколько примеров совпадений, когда вредоносные документы Excel и Word с поддержкой макросов порождают дочерний процесс, стек вызовов которого ссылается на vbe7.dll :
Здесь мы видим вредоносный файл XLL, открытый через Excel, порождающий законный браузер\_broker.exe для внедрения. Родительский стек вызовов указывает, что вызов создания процесса поступает от функции [xlAutoOpen](https://learn.microsoft.com/en-us/office/client-developer/excel/xlautoopen):
То же самое дополнение полезно и для событий загрузки библиотеки и реестра. Ниже приведен пример загрузки модуля CLR.DLL Microsoft Common Language Runtime из подозрительного стека вызовов (неподдерживаемая область памяти с разрешениями RWX) с помощью команды выполнения Sliver для загрузки внешних сборок .NET:
library where dll.name : "clr.dll" and
process.thread.Ext.call_stack_summary : "*mscoreei.dll|Unbacked*"
Охота за подозрительными изменениями определенных ключей реестра, таких как ключ «Выполнить» для обеспечения устойчивости, имеет тенденцию быть шумной и очень распространена в легальном программном обеспечении, но если мы добавим в логику сигнал стека вызовов, уровень подозрений значительно увеличится:
registry where
registry.path : "H*\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\\*"
// the creating thread's stack contains frames pointing outside any known executable image
and process.thread.Ext.call_stack_contains_unbacked == true
Еще один «забавный» пример — использование информации стека вызовов для обнаружения несанкционированных экземпляров основных системных процессов, которые обычно имеют очень специфические функции. Подписывая их обычные стеки вызовов, мы можем легко выявить выбросы. Например, WerFault.exe и wermgr.exe являются одними из наиболее привлекательных целей для маскировки:
Примеры совпадений:
Помимо использования данных стека вызовов для обнаружения подозрительного поведения, это также полезно, когда речь идет о более детальном исключении ложных срабатываний из обнаружения поведения. Это также помогает уменьшить возможности уклонения.
Хорошим примером является правило обнаружения необычных дочерних процессов Microsoft Office. Это правило используется для исключения splwow64.exe , который может быть законно порожден активностью печати. Исключение его с помощью процесса.executable создает возможность уклонения посредством вырезания или внедрения процесса, что может привести к тому, что дерево процессов будет выглядеть нормально. Теперь мы можем смягчить это уклонение, потребовав, чтобы такие процессы создавались из winspool.drv!OpenPrinter :
process where event.action == "start" and
process.parent.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSACCESS.EXE", "mspub.exe", "fltldr.exe", "visio.exe") and
// excluding splwow64.exe only if it’s parent callstack is coming from winspool.drv module
not (process.executable : "?:\\Windows\\splwow64.exe" and``_arraysearch(process.parent.thread.Ext.call_stack, $entry, $entry.symbol_info: ("?:\\Windows\\System32\\winspool.drv!OpenPrinter*", "?:\\Windows\\SysWOW64\\winspool.drv!OpenPrinter*")))
Чтобы уменьшить объемы событий, информация стека вызовов собирается на конечной точке и обрабатывается для обнаружения, но не всегда передается в потоковом режиме в событиях. Чтобы всегда включать стеки вызовов в потоковые события, в политике конечных точек доступен расширенный параметр:
Покрытие C2
Elastic Endpoint позволяет быстро обнаружить некоторые из лучших платформ C2, действующих на сегодняшний день. Ниже приведен снимок экрана, на котором обнаружены Nighthawk, BruteRatel, CobaltStrike и StealthVector от ATP41.
Заключение
Хотя эта возможность дает разработчикам преимущество перед современными технологиями обработки данных в памяти сегодня, злоумышленники, несомненно, будут разрабатывать новые инновации в попытках обойти ее. Вот почему разработчики уже усердно работают над созданием следующего набора передовых методов обнаружения в памяти.
