IoC hunting и pivoting

 Не путайте 'IoC hunting' и 'Threat hunting', так как первое всегда находит известные угрозы, а второе - неизвестные.

Из Твиттера.

Из общения с различными кандидатами на роль работников SOC - аналитики операционных линий, методологи и даже потенциальные менеджеры SOC - сложилось мнение о некоторой недооценке значимости Threat Intelligence Platform (TIP) для аналитиков SOC, а также непонимании разницы между Threat hunting и IoC Hunting. В этой заметке постараюсь очень поверхностно описать сценарий.

Мы все хорошо себе представляем цикл расследования инцидента, прекрасно описанный в книжке, с которой всем настоятельно рекомендую ознакомиться, - в процессе расследования мы обнаруживаем новые объекты, откуда извлекаем новые артефакты, которые нам позволяют обнаружить новые объекты, из которых вновь можно извлечь новые артефакты.... Примитивным примером может быть обнаружение обращений на вредоносные C&C по логам Web-прокси, выявление бинаря, производящего такие попытки соединения, анализ этого бинаря и извлечение новых C&C, проверка новых C&C по логам прокси и обнаружение новых предположительно скомпрометированных машин и новых бинарей, из которых также можно извлечь C&C и т.п.

Но хуже чуть представляется похожий цикл по релевантному TI. Он тоже несложен:

1. У нас появились первые IoC. 
2. На основе имеющихся IoC по данным TI находим связанные IoC. Здесь масса примеров как для хостовых (хеш, путь, ветку реестра, имя файла, размер, подписант,), так и для сетевых (URL, IP, port, site, User-Agent, MTA, Subject, имя вложения, ) индикаторов - на практике IoC-ом может быть все, за что можно зацепиться с допустимой долей ложных срабатываний. Поиск по IoC-ам связанных IoC-ов обычно называется IoC pivoting, цель - найти больше релевантных индикаторов и тем самым увеличить вероятность обнаружения, в предположении, что атакующие будут переиспользовать какие-либо инструменты в нашем конкретном сценарии, и их за это можно будет зацепить. Примеры ниже не претендуют на полноту и даны лишь для понимания:
1. Для downloader-а можно поискать  тех, кого он даунлодит (хеши,), с каких URL-ов (IP, сайт, URL,), какие он при этом использует User-Agent
2. Для URL можно поискать кто еще использует его как C&C (хеши)
3. Для дропперов можно посмотреть кого они дропают и запускают (хеши)
4. Если есть какие-либо фаззи-хеши, можно поискать похожие хеши и уже по ним посмотреть дропперов, даунлоадеров и командные центры
5. Для домена можно поискать IP и другие домены на этом же IP, а также контактную информацию (имя, email), по которой можно найти другие домены с такими же контактами (из-за GDPR сало затруднительно, как раз пример как privacy разбирает security и наоборот...)
6. Можно посмотреть parent-child связи: кого обычно запускал наш IoC (хеш), и кто, в свою очередь, обычно запускал его (хеш)
7. Можно на имеющийся сэмпл написать Yara-правила и с помощью их поискать другие сэмплы в коллекции (особенно здорово, когда есть своя огромная коллекция, но общие - тоже прекрасный источник)
8. ...  в зависимости от ситуации можно придумать массу подходящих сценариев размножения IoC...
3. Размножив IoC-и - переходим к IoC hunting, т.е. поиску всего, что получили в результате pivot-инга по имеющимся у нас логам EDR, NFT, NGFW, MailGW, WebGW, ... - у кого что есть.
4. В рамках IoC hunting-а могут быть обнаружены совпадения, которые надо расследовать, и, если мы имеем дело с реальным инцидентом, все повторяем: извлекаем новые IoC-и, размножаем их в рамках pivoting-а и хантим.

Заключительные мысли

1. Первые IoC можно получать не только из собственных инцидентов (хотя, очевидно, собственную практику расследования инцидентов следует обязательно превращать в TI), но и из публичных источников: отчеты о каких-либо кампаниях, новых инструментах или техниках. Для этого должна быть выделена функциях/роль, которая будет работать со всевозможным TI, превращая его в конечном счете в детектирующую логику и\или обогащения. По сути, эта функция работает в бесконечном операционном цикле: Получение IoC -> IoC Pivoting -> IoC Hunting -> Обнаружение (?) 
2. IoC Pivoting и IoC Hunting в обязательном порядке должны проводиться в рамках работ по расследованию инцидентов. Фактически, расследование инцидентов не может быть эффективным без данных TI (данной теме посвящена книжка, которую я также настоятельно рекомендую прочитать)
3. Использование просто IoC-ов из рассылок крайне малоэффективно. Как мала вероятность попадания в точку, также мал и успех что-то "наловить" по публично известным IoC-ам. Поэтому, чтобы хоть как-то повысить результативность детекта по IoC-ам, обязателен IoC pivoting непосредственно перед IoC hunting-ом. И здесь успех напрямую зависит от доступного объема TI, насколько значительно удастся размножить имеющиеся IoC-и за счет pivoting-а и насколько полученные релевантные IoC-и будут надежными.
4. Threat hunting (TH) ищет применение техники, я бы это назвал как TTP-based обнаружение, что больше относится к поведению. Для TH не важна и известность техники, в общем случае, TH проверяет гипотезу исследователя, которая далее может быть обернута в техники-тактики и обвешана детектами разного типа, включая и поведенческие. IoC hunting ищет использование известных инструментов на основе IoC - примитивных индикаторов, в основании Пирамиды боли. TH и IoC Hunting ни в коем случае не следует противопоставлять, так как прекрасно дополняют друг друга и могут являться разными уровнями\этапами обнаружения.