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

Графовый анализ сетевой инфраструктуры (сетевой граф) стал первым внутренним инструментом, который мы встроили во все публичные продукты компании. Прежде чем создавать свой сетевой граф, мы проанализировали многие подобные разработки на рынке и не нашли ни одного продукта, который бы удовлетворял нашим собственным потребностям. В этой статье мы расскажем о том, как мы создавали сетевой граф, как его используем и с какими трудностями столкнулись.

Дмитрий Волков, CTO Group-IB и глава направления киберразведки

Что умеет сетевой граф Group-IB?

Расследования

С момента основания Group-IB в 2003 году и по настоящее время идентификация, деанон и привлечение киберпреступников к ответственности являются главным приоритетом в нашей работе. Ни одно расследование кибератаки не обходилось без анализа сетевой инфраструктуры атакующих. В самом начале нашего пути это была довольно кропотливая «ручная работа» по поиску взаимосвязей, которые могли помочь в идентификации преступников: информация о доменных именах, IP-адресах, цифровых отпечатках серверов и др.

Большинство атакующих стараются действовать максимально анонимно в сети. Однако, как и все люди, они допускают ошибки. Основная задача такого анализа — найти «белый» или «серый» исторические проекты злоумышленников, которые имеют пересечения с вредоносной инфраструктурой, используемой в актуальном инциденте, который мы расследуем. Если удается обнаружить «белые проекты», то найти атакующего, как правило, становится тривиальной задачей. В случае с «серыми» на поиск уходит больше времени и усилий, так как их владельцы стараются анонимизировать или скрыть регистрационные данные, однако шансы остаются достаточно высокими. Как правило, в начале своей преступной деятельности атакующие уделяют меньше внимания собственной безопасности и делают больше ошибок, поэтому чем глубже мы сможем погрузиться в историю, тем выше шансы на успешное расследование. Именно поэтому сетевой граф с хорошей историей – крайне важный элемент такого расследования. Проще говоря, чем более глубокими историческими данными обладает компания, тем качественнее ее граф. Допустим, история в 5 лет может помочь раскрыть, условно, 1-2 из 10 преступлений, а история за 15 лет дает шансы на раскрытие всех десяти.

Выявление фишинга и мошенничества

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

Поиск бэкендов

Этот процесс необходим, чтобы установить, где реально находится вредоносный сервер.
99% кардшопов, хакерских форумов, множество фишинговых ресурсов и других вредоносных серверов скрываются как за собственными прокси-серверами, так и за прокси легитимных сервисов, например, Cloudflare. Знание о реальном бэкенде очень важно для расследований: становится известен хостинг-провайдер, у которого можно изъять сервер, появляется возможность построить связи с другими вредоносными проектами.

Например, у вас есть фишинговый сайт для сбора данных банковских карт, который резолвится в IP-адрес 11.11.11.11, и адрес кардшопа, который резолвится в IP-адрес 22.22.22.22. В ходе анализа может выясниться, что и у фишингового сайта, и у кардшопа общий IP-адрес бэкенда, например, 33.33.33.33. Эти знания позволяют построить связь между фишинговыми атаками и кардшопом, на котором, возможно, продают данные банковских карт.

Корреляция событий

Когда у вас есть две разные сработки (допустим, на IDS) с разным вредоносным ПО и разными серверами для управления атакой, вы будете рассматривать их как два независимых события. Но если есть хорошая связь между вредоносными инфраструктурами, то становится очевидно, что это не разные атаки, а этапы одной, более сложной многоступенчатой атаки. А если одно из событий уже атрибутировано до какой-либо группы атакующих, то и второе тоже можно атрибутировать до этой же группы. Конечно, процесс атрибуции значительно более сложный, поэтому относитесь к написанному как к простому примеру.

Обогащение индикаторов

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

Выявление паттернов

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

Почему мы создали свой сетевой граф?

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

Проблема
Решение

Отсутствие поставщика с разными коллекциями данных: доменами, passive DNS, passive SSL, DNS-записями, открытыми портами, запущенными сервисами на портах, файлами, взаимодействующими с доменными именами и IP-адресами. Пояснение. Обычно поставщики предоставляют отдельные типы данных, и, чтобы собрать полную картину, нужно покупать подписки у всех. Но и при этом не всегда удается получить все данные: некоторые поставщики passive SSL предоставляют данные только о сертификатах, выпущенных доверенными CA, а покрытие самоподписанных сертификатов у них крайне плохое. Другие предоставляют данные и по самоподписанным сертификатам, но собирают их только со стандартных портов.
Мы собрали все вышеуказанные коллекции сами. Например, для сбора данных о SSL-сертификатах мы писали собственный сервис, который собирает их и от доверенных CA, и с помощью сканирования всего IPv4-пространства. Сертификаты собирались не только с IP, но и со всех доменов и поддоменов из нашей базы: если у вас есть домен example.com и его поддомен www.example.com и все они резолвятся в IP 1.1.1.1, то при попытке получения SSL-сертификата с порта 443 по IP, домену и его поддомену вы можете получить три разных результата. Для сбора данных по открытым портам и запущенным сервисам пришлось делать свою распределенную систему сканирования, потому что у других сервисов IP-адреса сканирующих серверов часто находились в «черных списках». Наши сканирующие серверы тоже попадают в «черные списки», но результат обнаружения нужных нам сервисов выше, чем у тех, кто просто сканирует как можно больше портов и продает доступ к этим данным.

Отсутствие доступа ко всей базе исторических записей. Пояснение. Каждый нормальный поставщик имеет хорошую накопленную историю, но по естественным причинам доступ ко всем историческим данным мы как клиент получить не могли. Т.е. можно получить всю историю по отдельной записи, например, по домену или IP-адресу, но нельзя увидеть историю всего — а без этого нельзя увидеть полную картину.
Чтобы собрать как можно больше исторических записей по доменам, мы скупали различные базы, парсили множество открытых ресурсов, которые обладали этой историей (хорошо, что таких было много), договаривались с регистраторами доменных имен. Все обновления в наших собственных коллекциях, конечно же, хранятся с полной историей изменений.

Все существующие решения позволяют строить граф в ручном режиме. Пояснение. Допустим, вы купили множество подписок от всех возможных поставщиков данных (как правило, их называют «обогатители»). Когда вам нужно построить граф, вы «руками» даете команду достроить от нужного элемента связи, далее из появившихся элементов выбираете нужные и даете команду достроить связи от них и так далее. В этом случае ответственность за то, насколько качественно будет построен граф, полностью лежит на человеке.
Мы сделали автоматическое построение графов. Т.е. если вам нужно построить граф, то связи от первого элемента строятся автоматически, далее от всех последующих — тоже. Специалист лишь указывает глубину, с которой нужно строить граф. Сам процесс автоматической достройки графов простой, но другие вендоры не реализуют его потому, что он дает огромное количество нерелевантных результатов и этот недостаток нам тоже пришлось учитывать (см. ниже).

Множество нерелевантных результатов — это проблема всех графов по сетевым элементам. Пояснение. Например, «плохой домен» (участвовал в атаке) связан с сервером, с которым за последние 10 лет связано 500 других доменов. При ручном добавлении или автоматическом построении графа все эти 500 доменов тоже должны вылезти на граф, хотя не имеют отношения к атаке. Или, например, вы проверяете IP-индикатор из отчета вендора по безопасности. Как правило, такие отчеты выходят со значительной задержкой и часто охватывают год и более. Скорее всего, в момент, когда вы читаете отчет, сервер с этим IP-адресом уже сдан в аренду другим людям с другими связями, и построение графа приведет к тому, что вы опять получили нерелевантные результаты.
Мы обучили систему выявлять нерелевантные элементы по той же логике, как это делали наши эксперты руками. Например, вы проверяете плохой домен example.com, который сейчас резолвится в IP 11.11.11.11, а месяц назад — в IP 22.22.22.22. С IP 11.11.11.11, кроме домена example.com, связан еще example.ru, а с IP 22.22.22.22 связано 25 тысяч других доменов. Система, как и человек, понимает, что 11.11.11.11 — это, скорее всего, выделенный сервер, а поскольку домен example.ru схож по написанию с example.com, то, с большой вероятностью, они связаны и должны быть на графе; а вот IP 22.22.22.22 принадлежит shared hosting, поэтому все его домены выносить на граф не нужно, если нет других связей, показывающих, что какой-то из этих 25 тысяч доменов тоже нужно вынести (например, example.net). Прежде чем система поймет, что связи нужно разорвать и не выносить часть элементов на граф, она учитывает множество свойств элементов и кластеров, в которые эти элементы объединены, а также прочность текущих связей. Например, если у нас на графе маленький кластер (50 элементов), в который входит плохой домен, и еще один большой кластер (5 тысяч элементов) и оба кластера связаны связью (линией) с очень малой прочностью (весом), то такая связь разорвется и элементы из большого кластера будут удалены. Но если связей между маленьким и большим кластерами будет много и их прочность будет постепенно повышаться, то в этом случае связь не разорвется и на графе останутся нужные элементы из обоих кластеров.

Не учитывается интервал владения сервером, доменом. Пояснение. Срок регистрации «плохих доменов» рано или поздно истекает, и их снова покупают для вредоносных или легитимных целей. Даже у bulletproof-хостингов серверы сдаются в аренду разным хакерам, поэтому критично знать и учитывать интервал, когда тот или иной домен/сервер находились под управлением одного владельца. Мы часто сталкиваемся с ситуацией, когда сервер с IP 11.11.11.11 сейчас используется как C&C для банковской бота, а еще 2 месяца назад с него управляли Ransomware. Если строить связь, не учитывая интервалы владения, то будет похоже, что между владельцами банковской бот-сети и вымогателями есть связь, хотя на самом деле ее нет. В нашей работе такая ошибка является критичной.
Мы научили систему определять интервалы владения. Для доменов это относительно просто, ведь в whois часто указаны даты начала и истечения регистрации и, когда есть полная история изменений whois, определить интервалы легко. Когда у домена срок регистрации не истек, но его управление было передано другим владельцам, тоже можно отследить. Для SSL-сертификатов такой проблемы нет, ведь он выпускается один раз, не продляется и не передается. Но у самоподписанных сертификатов нельзя доверять датам, указанным в сроках действия сертификата, потому что можно сгенерировать SSL-сертификат сегодня, а дату начала действия сертификата указать с 2010 года. Сложнее всего определять интервалы владения для серверов, ведь даты и сроки аренды есть только у хостинг-провайдеров. Чтобы определять период владения сервером, мы начали использовать результаты сканирования портов и создания отпечатков запущенных служб на портах. По этой информации мы достаточно точно можем сказать, когда у сервера менялся владелец.

Мало связей. Пояснение. Сейчас не проблема даже бесплатно получить список доменов, в whois которых указан определенный адрес электронной почты, или узнать все домены, которые были связаны с определенным IP-адресом. Но, когда речь идет о хакерах, которые делают все возможное, чтобы их было тяжело отслеживать, нужны дополнительные «трюки», которые позволят найти новые свойства и построить новые связи.
Мы потратили много времени на исследование того, как можно извлекать данные, которые недоступны, обычным способом. Описывать тут, как это работает, мы не можем по понятным причинам, но при определенных обстоятельствах хакеры при регистрации доменов или аренде и настройке серверов допускают ошибки, которые позволяют узнать адреса электронной почты, псевдонимы хакеров, адреса бэкендов. Чем больше связей вы извлекаете, тем точнее можно строить графы.

Как работает наш граф

Чтобы начать использовать сетевой граф, нужно ввести в поисковую строку домен, IP-адрес, email или отпечаток SSL-сертификата. Есть три условия, которыми может управлять аналитик: время, глубина шагов и очистка.

Время

Время – дата или интервал, когда искомый элемент использовался для вредоносных целей. Если не указать этот параметр, то система сама определит последний интервал владения этим ресурсом. Например, 11 июля компания Eset опубликовала отчет о том, как Buhtrap использует для кибершпионажа 0-day эксплоит. В конце отчета есть 6 индикаторов. Один из них secure-telemetry[.]net был заново зарегистрирован 16 июля. Поэтому если вы будете строить граф после 16 июля, то будете получать нерелевантные результаты. Но если указать, что этот домен использовался до этой даты, то на граф попадают 126 новых доменов, 69 IP-адресов, которые не указаны в отчете Eset:

• ukrfreshnews[.]com
• unian-search[.]com
• vesti-world[.]info
• runewsmeta[.]com
• foxnewsmeta[.]biz
• sobesednik-meta[.]info
• rian-ua[.]net
• и др.

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

Самое замечательное, что вы получаете это результат в течение одной секунды и вам уже не требуется тратить дни на анализ данных. Безусловно, такой подход иногда в разы сокращает время на расследования, что часто бывает критичным.

Количество шагов или глубина рекурсии, с которой будет строиться граф

По умолчанию глубина равна 3. Это означает, что от искомого элемента будут найдены все напрямую связанные элементы, потом это каждого нового элемента будут построены новые связи до других элементов, и уже от новых элементов с прошлого шага будут новые элементы.

Возьмем пример, не связанный с APT и 0-day эксплойтами. Недавно на Хабре описывали интересный кейс с мошенничеством, связанный с криптовалютами. В отчете упоминается домен — themcx[.]co, используемый мошенниками для хостинга сайта якобы обменника Miner Coin Exchange и phone-lookup[.]xyz, для привлечения трафика.

Из описания понятно, что схема требует достаточно большой инфраструктуры для привлечения трафика на мошеннические ресурсы. Мы решили посмотреть на эту инфраструктуру, построив граф в 4 шага. На выходе получили граф с 230 доменами и 39 IP-адресами. Далее разбиваем домены на 2 категории: те, что похожи на сервисы работы с криптовалютами и те, что предназначены для нагона трафика через сервисы проверки телефонов:

Связаны с криптовалютой
Связан с сервисами пробива телефонов

coinkeeper[.]cc
caller-record[.]site.

mcxwallet[.]co
phone-records[.]space

btcnoise[.]com
fone-uncover[.]xyz

cryptominer[.]watch
number-uncover[.]info

Очистка

По умолчанию опция “Очистка графа” включена и все нерелевантные элементы будут удаляться с графа. К слову, она использовалась и во всех предыдущих примерах. Предвижу естественный вопрос: а как же сделать так, чтоб не удалилось что-то важное? Отвечу: для аналитиков, которые любят строить графы руками, автоматизированную очистку можно отключить и выбрать количество шагов = 1. Далее аналитик сможет достраивать граф от нужных ему элементов и удалять нерелевантные поставленной задаче элементы с графа.

Уже на графе аналитику становятся доступны история изменений whois, DNS, а также открытых портов и запущенных на них сервисов.

Финансовый фишинг

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

В данном случае нам очень помог автоматизированный графовый анализ. Взяв один из их доменов — lloydsbnk-uk[.]com, мы через несколько секунд построили граф с глубиной в 3 шага, который выявил более 250 вредоносных доменов, которые были использованы этой группой с 2015 года и продолжают использоваться. Некоторые из этих доменов уже выкуплены банками, но по историческим записям видно, что ранее они были зарегистрированы на атакующих.

Для наглядности на рисунке показан граф с глубиной в 2 шага.

Примечательно, что уже в 2019 году атакующие несколько изменили тактику и начали регистрировать не только домены банков для хостинга веб-фишинга, но и домены различных консалтинговых компаний для отправки фишинговых писем. Например, домены swift-department.com, saudconsultancy.com, vbgrigoryanpartners.com.

Cobalt gang

В декабре 2018 года хакерская группа Cobalt, специализирующаяся на целенаправленных атаках на банки, провела рассылку от имени Национального банка Казахстана.

В письмах были ссылки на hXXps://nationalbank.bz/Doc/Prikaz.doc. Скачиваемый документ содержал макрос, запускающий powershell, который попытается загрузить и исполнить файл с hXXp://wateroilclub.com/file/dwm.exe в %Temp%einmrmdmy.exe. Файл %Temp%einmrmdmy.exe aka dwm.exe — CobInt stager, настроенный на взаимодействие с сервером hXXp://admvmsopp.com/rilruietguadvtoefmuy.

Представьте, что у вас нет возможности получить эти фишинговые письма и провести полный анализ вредоносных файлов. Граф по вредоносному домену nationalbank[.]bz сразу показывает связи с другими вредоносными доменами, атрибутирует это до группы и показывает какие файлы использовались в атаке.

Возьмем из этого графа IP-адрес 46.173.219[.]152 и построим по нему граф в один проход и выключим очистку. С ним связано 40 доменов, например, bl0ckchain[.]ug
paypal.co.uk.qlg6[.]pw
cryptoelips[.]com

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

Если заново построить граф по nationalbank[.]bz, но отключив алгоритм очистки графа, то на него попадает более 500 элементов и большая часть из которых не имеет отношения ни к группе Cobalt, ни к их атакам. Пример, как выглядит такой граф приведен ниже:

Заключение

После нескольких лет тонкой настройки, тестирований в реальных расследованиях, исследований угроз и охоты за атакующими нам удалось не только создать уникальный инструмент, но и изменить отношение к нему экспертов внутри компании. Вначале технические эксперты хотят полного контроля над процессом построения графа. Убедить их в том, что автоматическое построение графа сможет делать это лучше, чем человек с многолетним опытом, было крайне сложно. Все решило время и многократные “ручные” проверки результатов того, что выдавал граф. Теперь наши эксперты не просто доверяют системе, но и используют полученные ею результаты в ежедневной работе. Эта технология работает внутри каждой из наших систем и позволяет лучше выявлять угрозы любого типа. Интерфейс для ручного анализа графа встроен во все продукты Group-IB и значительно расширяет возможности для хантинга за киберпреступностью. Это подтверждают отзывы аналитиков со стороны наших клиентов. А мы, в свою очередь, продолжаем обогащать граф данными и работать над новыми алгоритмами, использующими искусственный интеллект, для максимально точного сетевого графа.

Источник: habr.com