Гипотезы из KEV++

Для зрелого Threat hunting-а (TH) требуется системный подход к выработке гипотез. Подход "в лоб" - это покрытие правилами обнаружения известных на данный момент TTП, взяв за основу MITRE ATT&CK. Однако, на определенном уровне понимания, привязка к MITRE не очень хороша по множеству причин, как минимум: а) логика обнаружения разрабатывается на процедуру, а с процедурами в ATT&CK, мягко сказать, не очень, б) техники появляются с опозданием в несколько месяцев, в) отечественное ПО там никак не представлено, и не будет. Вариант ad-hoc, или даже регулярного, чтения Твиттеров едва ли можно назвать "системным". Лично мне больше нравится вариант из Operations , когда анализ выявленных и расследованных инцидентов ложится в основу создания новых правил обнаружения, но такой подход сильно завязан на объем, т.е. хорошего покрытия невозможно добиться без стабильного потока разноплановых инцидентов для анализа. В любом случае, для создания хантов следует использовать все возможные источники, поэтому никогда не лишне об этом задумываться.

Несмотря на то, что я не очень хорошо отношусь к "классическим" подходам по управлению уязвимостями и пропагандирую концепцию Assume vulnerable, работа по сбору и анализу уязвимостей не является бесполезной, как минимум, потому, что для любой эксплуатации принципиально наличие уязвимости. В рамках ТН мы как раз и пытаемся обнаружить эксплуатацию, а раз последняя невозможна без наличия уязвимости, анализ процесса эксплуатации уязвимости может служить основой для создания гипотез ТН.

За основу возьмем тендовые уязвимости или KEV, а лучше и то и другое, и прочие национальные аналоги, тем более, если мы работаем в соответсвующем регионе. В соответствии с принципом Assume Vulnerable мы предполагаем, что уязвимость точно есть (что недалеко от реальности, ибо если сегодня это RCE залатали, совсем не значит, что послезавтра новый функционал не приведет к появлению такой же уязвимости с тем же сценарием развития), анализируем как бы развивалась атака в случае успешной эксплуатации, и уже это потенциальное развитие вследствие эксплуатации и есть наша ТН-гипотеза, которую мы покрываем нашими хантами и прочими корреляционными правилами. Чтобы не насиловать воображение и получить объективную картину можно проэксплуатировать уязвимость в лабе, посмотреть какие события телеметрии нападают, придумать за что можно было бы зацепиться и на это написать ханты. Множество разных уязвимостей одного типа ведут к одному и тому же развитию, поэтому множеству уязвимостей будут соответствовать небольшое количество правил обнаружения, т.е. с учетом того, что в KEV - несколько сотен (немногим более 1000) уязвимостей, работа по анализу гипотез из трендовых уязвимостей выглядит вполне выполнимой. А, поскольку есть добросовестные ребята, которые вполне своевременно, системно, пополняют списки трендовых уязвимостей, деятельность по анализу гипотез на их базе также приобретает вожделенную системность. Как сказано в начале этой заметки, для возможности атаки обязательно наличие уязвимости, поэтому, если мы адресуем все эксплуатируемые уязвимости, атака едва ли останется незамеченной.

Чтобы было понятно, как это работает, рассмотрим несколько совсем банальных примеров. Если уязвимость в серверном приложении ведет к RCE, то следствием ее эксплуатации будет запуск чего-то серверным приложением - на это можно сделать детект. Если уязвимость ведет к повышению привилегий, то обнаружение можно построить на изменении integrity level-а дочернего процесса относительно родительского. Если мы имеем дело с Path/Directory traversal, то, во-первых, разумно превентивно поправить права доступа к файловой системе, а, во-вторых, сделать правила на обнаружение попыток подозрительного доступа к файловой системе демонов серверных приложений. И т.п. Описание логики обнаружения на базе анализа уязвимостей - работа, где описание деталей заслуживает, как минимум, специализированной статьи, здесь же моя цель - только передать идею.

Да, любая атака начинается с уязвимости, но существующие базы уязвимостей не покрывают все их классы, поэтому предлагаемый подход не претендует на универсальность, и нам по-прежнему надо продолжать искать новые источники вдохновения для нашего Detection Engineering-а, не забывая\не забивая на упомянутые и широко используемые: а) практика MDR/DFIR, б) практика анализа защищенности, в) каталоги ТТП типа ATT&CK, г) данные исследований угроз и прочий Threat Intel, д) статьи, твиттеры и другие релевантные публикации исследователей.