Розслідуючи справи, пов'язані з фішингом, бот-мережами, шахрайськими транзакціями та злочинними хакерськими групами, експерти 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 року. Найскладніше визначати інтервали володіння для серверів, адже дати та терміни оренди є лише у хостинг-провайдерів. Щоб визначити період володіння сервером, ми почали використовувати результати сканування портів та створення відбитків запущених служб на портах. За цією інформацією ми можемо точно сказати, коли у сервера змінювався власник.

Мало зв'язків. Пояснення. Зараз не проблема навіть безкоштовно отримати список доменів, у якихвказана певна адреса електронної пошти, або дізнатися всі домени, які були пов'язані з певною 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.
paypal.co.uk.qlg6[.]pw
cryptoelips[.]com

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

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

Висновок

Після кількох років тонкого налаштування, тестувань у реальних розслідуваннях, досліджень загроз та полювання за атакуючими нам вдалося не лише створити унікальний інструмент, а й змінити ставлення до нього експертів усередині компанії. Спочатку технічні експерти хочуть повного контролю за процесом побудови графа. Переконати їх у тому, що автоматична побудова графа зможе робити це краще за людину з багаторічним досвідом, було вкрай складно. Все вирішило час та багаторазові “ручні” перевірки результатів того, що видавав граф. Тепер наші експерти не просто довіряють системі, а й використовують отримані нею результати у щоденній роботі. Ця технологія працює всередині кожної з наших систем та дозволяє краще виявляти загрози будь-якого типу. Інтерфейс для ручного аналізу графа вбудований у всі продукти Group-IB і значно розширює можливості для хантінгу за кіберзлочинністю. Це підтверджує відгуки аналітиків з боку наших клієнтів. А ми, у свою чергу, продовжуємо збагачувати граф даними та працювати над новими алгоритмами, які використовують штучний інтелект для максимально точного мережевого графа.

Джерело: habr.com