Трафик под микроскопом: ML‑модель в поиске новых сетевых «отпечатков» вредоносов

С вами вновь Ксения Наумова из экспертного центра безопасности вместе с Игорем Кабановым из ML‑команды Positive Technologies. Однажды мы построили ML‑модель на сетевом трафике, обучили её на реальных сетевых сессиях и запустили в песочнице PT Sandbox для усиления возможностей по обнаружению вредоносов. Но команда машинного обучения не останавливалась на достигнутом. Вместе мы провели серию новых экспериментов, расширили набор входных признаков и протестировали модель на более сложных сценариях, что привело к обновлению модели и ещё большему детект‑рейту.

В этой статье мы подробно расскажем про обновленные признаки нашей модели, их технической реализации и о том, как они интегрированы в разработанную ML‑модель. Вы узнаете, какие задачи пришлось решить, какие ошибки пришлось исправить, как и почему мы меняли набор признаков и какое новое ВПО благодаря этому нам удалось поймать. 

Приятного чтения!

Краткое введение: основные изменения в ML-модель

Относительно подхода, описанного в нашей прошлой статье, мы пересмотрели формирование набора признаков модели. Изначальное решение строилось на основе экспертных знаний о поведении ВПО, за счет чего feature set носил более точечный характер. То есть строились onehot‑признаки по конкретным интересующим нас значениям. Это позволяло сохранять высокую интерпретируемость вердиктов модели и более тонко контролировать ее поведение на отдельно взятых семплах. Однако со временем нам удалось накопить уже достаточно данных с разных источников, чтобы иметь возможность полноценно опираться на нашу выборку, доверяя репрезентативности распределений. За счет этого мы смогли перестроить наш набор признаков с точечного экспертного характера на статистический, на основе данных.

Разбор обновленных признаков на примерах

Для наглядности изменений и влияния признаков на модель будем смотреть на SHAP‑values. В качестве примера посмотрим два признака — один относится к заголовку Content‑Type в HTTP‑Response, другой — к заголовку User‑Agent в HTTP‑Request.

Пример 1. Признак для Content-Type

Признак для Content‑Type — это бинарный признак, являющийся сигналом наличия какого‑либо типа контента в ответе http‑транзакции. При этом ранее этот признак обозначал наличие одного конкретного типа контента (и в сочетании с ним шел ряд других признаков для других типов контента). В обновленной версии мы расширили эти признаки таким образом, что каждый из них обозначает наличие Content‑Type, относящегося к какой‑либо группе. В отличие от старого onehot‑подхода это позволяет заложиться на те значения, которых мы не имеем в нашей обучающей выборке, но имеем подобные, и хотим, чтобы эти значения вносили одинаковый вклад в вердикт модели.

Посмотрим на SHAP‑values (голубые точки по оси Y) и распределение значений (серая гистограмма на фоне) старого признака на обучающей выборке.

По гистограмме видно, что в силу точечности признака положительное значение встречается крайне редко, а SHAP‑values (роль этого признака) при нулевом значении почти во всех случаях крайне близка к нулю.

Теперь такой же график построим для обновленного признака.

Как мы видим, за счет группировки значений заголовков удалось увеличить долю семплов с положительным значением признака и, соответственно, увеличить влияние признака в случае нулевого значения.

Пример 2. Признак для User-Agent

Признак для заголовка User‑Agent имеет точно такую же природу, как и рассмотренный выше. В этом случае старый признак соответствовал наличию конкретного браузерного User‑Agent (без учета версии), а новый соответствует принадлежности User‑Agent к группе браузерных User‑Agent.

Посмотрим, как изменились показатели признака по графикам.

Для этого признака группировка дала еще более выраженный эффект, так как до обновления распределение значений признака было похоже на случай с Content‑Type, а после распределение развернулось в обратную сторону в пользу положительного значения. Происходит это потому, что в случае точечного признака на конкретный браузерный User‑Agent вероятность встретить этот User‑Agent ниже, чем любой другой. Однако в общем случае мы не хотим перетягивать вердикт модели, исходя из одного конкретного User‑Agent. Нас больше интересует, какого типа User‑Agent в запросе, а браузерный тип является самым распространенным и составляет около 70% нашей выборки.

Также по графику видно, что сами значения SHAP‑values стали гораздо более четко разделены между значениями самого признака. Этот кейс показывает, что даже с точки зрения прозрачности и интерпретируемости модели уход от точечных признаков иногда приводит к положительному результату.

Прочие обновления признаков

Помимо двух примеров, которые мы разобрали выше, такого же рода изменения были сделаны для всех других заголовков. В результате от старого onehot‑подхода, где каждый признак сигнализировал наличие конкретного значения заголовка, мы перешли к групповым признакам. Последние носят более полный характер с точки зрения генеральной совокупности, а вместе с этим позволяют заложиться на новые значения в реальных данных и передавать в модель не набор отдельно взятых флагов, а целостную информацию о поведении внутри запросов и сессий.

Также были добавлены различные числовые признаки по типу энтропии значений заголовков, длины значений, непосредственно сами значения, если они являются числовыми в общем случае, и др., что тоже добавило статистической информации в набор признаков.

В результате мы получили feature‑сет на 26% больше, несмотря на объединение признаков в группы, так как помимо группировки само покрытие обрабатываемых значений увеличилось, соответственно число групповых признаков получилось близко к изначальному числу onehot‑признаков, также были добавлены числовые признаки.

К моменту, когда мы начали работу над обновлениями, нам удалось собрать крупную и качественную выборку данных, которой мы могли доверять с точки зрения статистики и распределений. Соответственно, все группировки, наполнение групп значениями, а также отбор признаков производились на основе распределения этих признаков на данных так, чтобы feature‑сет содержал максимальное количество статистической информации и при этом был лишен избыточных «мусорных» данных.

Общее сравнение feature-сетов до и после обновлений

Для более общего сравнения посмотрим на график SHAP‑values, отображающий топ признаков по вкладу в вердикт модели.

Последней строкой обозначен общий вклад всех прочих признаков. Как видно из графика, за счет группировки удалось немного сгладить влияние признаков и добавить несколько новых признаков, вносящих заметный вклад в вердикты модели.

Качество модели после обновления

На каждом шаге наших изменений мы измеряли качество на валидационной выборке, которая была сформирована так, чтобы быть наиболее приближенной к данным, с которыми наша модель потенциально столкнется на инференсе.

Суммарно по результатам всех вышеперечисленных изменений нам удалось улучшить качество модели на ~12% (около 8% прирост по precision и около 15% по F1-score).

Однако с момента выхода модели в PT Sandbox валидационная выборка уже не является реальным показателем качества, а скорее используется, как вспомогательный инструмент для контроля последовательных изменений перед выпуском новой версии. Соответственно, реальные метрики, которые нас интересуют, должны измеряться на реальных данных работы модели в продукте. Если говорить конкретно, то с точки зрения бизнес‑вэлью наиболее важной для нас метрикой оказалось соотношение числа уникальных детектов модели (когда из всех модулей продукта только ей удалось детектировать вредоносную активность) к числу ложных срабатываний. При этом уникальные детекты имеют очень большую ценность, поэтому допустимым соотношением является 1 к 2. Именно такое соотношение мы имели на момент выхода в продукт первой версии модели. После всех последовательных изменений по последним данным модель имеет соотношение близкое к 1 к 1.

Стоит отметить, что данное соотношение можно улучшать с двух сторон: со стороны уменьшения фолзов и со стороны увеличения числа уникальных детектов. Общее число сработок модели будет либо уменьшаться, либо расти, соответственно. Важно соблюдать баланс в этих вариантах улучшений, чтобы модель не переставала обнаруживать новые вредоносы и успешно их блокировать. Это нам удается, как можно судить по конкретным кейсам, которые мы разобрали с нашими экспертами. Об этом дальше.

Интересные находки, их поведение на хосте и в трафике, а также интерпретация их моделью ML

В прошлой статье мы уже рассказывали о первых сетевых находках нового ВПО благодаря ML‑модели. Но, изучив сработки на потоке и улучшив набор признаков и алгоритм их процессинга, нам удалось обнаружить намного больше интересных, а самое главное, не детектируемых ранее сэмплов. Ниже поделимся частью из них (самыми интересными)!

1. Backdoor Oyster — 3836b9b8dc67fb82423365f1f0ff1c2ca6ca60e787673e72611bb023690cacda

Этот бэкдор мы встречали еще год назад, но в этот раз вирусописатели решили сбить детект и немного изменили сетевое взаимодействие. Благодаря сработке ML‑модели нам удалось обнаружить новую версию Oyster и успешно задетектировать его. Как можно заметить, основные триггеры для модельки в данном случае — это длина запроса, POST метод и нестандартный набор заголовков.

2. Loader (APT GOFFEE) — 2446f97c1884f70f97d68c2f22e8fc1b9b00e1559cd3ca540e8254749a693106

В случае этого загрузчика группировки COFFEE (мы писали о ней прошлым летом) модель смогла определить вредоносность благодаря ряду признаков, самые значимые из которых — это параметры в URL‑запросе, где передаются сведения о системе и пользователе, а также небольшое количество и специфичное следование заголовков ответа.

3. Stealer JustAskJacky — f05855fc1041a19649f2486ceb6a68b259d8969275f8ef455f17207f09be653b

Для JustAskJacky приговор подписали и устаревший User‑Agent, и URL‑адрес, заголовки и, конечно же, само тело, содержащее json с данными о системе. Сложив все эти данные, ML‑модель обнаружила недетектируемый ранее стилер.

4. Stealer — f21483536cbd1fa4f5cb1e996adbe6a82522ca90e14975f6172794995ed9e9a2

Как можно увидеть, данный стилер формирует запрос с довольно специфичной URL‑строкой, а в теле передается явно что‑то интересное — зашифрованные данные о параметрах и ключах. Расположение заголовков и User‑Agent также заставляют усомниться в легитимности этой сессии. Еще заметим, что ответ сервера содержит мало заголовков и байтов в теле («132» и «ERROR»). Таким образом, модель ML, сложив веса, помечает данное сетевое взаимодействие как «вредоносное» и оказывается права.

5. Loader — 6aa9e5d0b9da7582cea7768f5845e1446c1995df41531e3f31ca91bc6125ef4f

У этого загрузчика краткость — сестра таланта, как и прямота — ему явно нечего скрывать. Во‑первых, в URL‑адресе он указывает специфичный ключ в формате uuid, во‑вторых, в параметре stage прямо прописывает, что это loader, ну и, в довершение, малое (всего 3) количество заголовков запроса добавляет еще немного подозрительности. Сложив все упомянутые факторы, которые считаются довольно нехарактерными для легитимных сессий, мы видим, как ML‑модель снова успешно обнаруживает новую угрозу, которая в данном случае оказывается неуспешной, так как сервер отвечает 400 — в ходе работы ВПО что‑то пошло не по задуманному сценарию.

Вывод

ML-модель на HTTP‑запросах очень помогает при анализе семплов в песочницах, особенно таких вредоносов, которые после запуска никоим образом не выдают себя на «скомпрометированном» хосте (не пытаются инжектиться в процессы, прописываться в реестры, сканировать файловую систему и сетевые интерфейсы и так далее), а просто обращаются на С2 и ждут ответа от сервера. Зачастую такие checkin‑запросы меняются от семпла к семплу, поэтому именно модель машинного обучения в силу своей гибкости и наличию нечетких проверок помогает обнаруживать то, что сигнатурные проверки могут пропускать, и в нашем случае она делает это отлично, что показывает количество вышеупомянутых находок!

Конечно, повторимся, что без конкретных контентосодержащих правил никуда не деться, это база, которая, увы или к счастью, будет во многих средствах защиты информации еще долгое время. Вместе с тем, ML здесь не соперник давно зарекомендовавшим себя сигнатурам, а полезный помощник, с которым будут обнаружены не только известные, но и новые угрозы, что в общей сумме повысит детектируемость вредоносов во всем продукте!

Если вам интересен процесс построения ML‑решений в сфере кибербезопасности, а также то, как новые подходы к признаковому пространству могут изменить эффективность обнаружения вредоносов, оставайтесь с нами и присоединяйтесь к телеграм‑чату ML‑команды позитива @falseposi.