Разследвайки случаи, свързани с фишинг, бот мрежи, измамни транзакции и престъпни хакерски групи, експертите на 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) с различен злонамерен софтуер и различни сървъри за управление на атаката, ще ги разглеждате като две независими събития. Но ако има добра връзка между злонамерените инфраструктури, става очевидно, че това не са различни атаки, а етапи от една, по-сложна многостепенна атака. И ако едно от събитията вече е приписано на някаква група атакуващи, то и второто може да бъде приписано на същата група. Разбира се, процесът на атрибуция е значително по-сложен, затова приемайте написаното като прост пример.

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

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

Идентификация на модели

Идентификацията на модели е необходима за ефективен лов. Графите позволяват не само намирането на свързани елементи, но и разкриването на общи свойства, които присъстват на определена група хакери. Знанието за такива уникални признаци позволява разпознаване на инфраструктурата на атакуващите още на етапа на подготовка и без доказателства, потвърдителни за атаката, като фишинг имейли или злонамерени програми.

Защо създадохме своя мрежов граф?

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

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

Липса на доставчик с различни колекции от данни: домейни, пасивен DNS, пасивен SSL, DNS записи, отворени портове, активни услуги на портовете, файлове, взаимодействуващи с домейни и IP адреси. Пояснение. Обикновено доставчиците предлагат отделни типове данни, и за да събереш пълната картина, е нужно да закупиш абонаменти от всички. Но дори и тогава не винаги успяваш да получиш всички данни: някои доставчици на пасивен 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 принадлежи на споделен хостинг, затова всички негови домейни не е нужно да бъдат изнасяни на графа, освен ако няма други връзки, които показват, че някой от тези 25 хиляди домейна трябва да бъде изнесен (например, example.net). Преди системата да разбере, че връзките трябва да бъдат прекъснати и част от елементите да не бъдат изнасяни на графа, тя взема предвид множество свойства на елементите и клъстерите, в които тези елементи са обединени, а също така и здравината на текущите връзки. Например, ако на графа имаме малък клъстер (50 елемента), в който влиза лошият домейн, и още един голям клъстер (5000 елемента), и двата клъстера са свързани с много слаба връзка (линия), то такава връзка ще бъде прекъсната и елементите от голямото клъстер ще бъдат премахнати. Но ако връзките между малкия и голямия клъстер са много и тяхната здравина постепенно се увеличава, то в този случай връзката няма да бъде прекъсната и на графа ще останат нужните елементи и от двата клъстера.

Не се взема предвид периода на притежание на сървъра, домейна. Обяснение. Срокът на регистрация на "лошите домейни" рано или късно изтича и те отново се купуват за злонамерени или легитимни цели. Дори при bulletproof хостинг, сървърите се отдават под наем на различни хакери, затова е критично важно да се знае и взема предвид периодът, когато определен домейн/сървър е бил под управлението на един собственик. Често се сблъскваме с ситуация, когато сървър с IP 11.11.11.11 в момента се използва като C&C за банков бот, а преди 2 месеца от него е бил управляван Ransomware. Ако изградите връзка, без да вземете предвид периодите на притежание, ще изглежда, че между собствениците на банковата бот мрежа и изнудвачите има връзка, въпреки че всъщност няма такава. В нашата работа такава грешка е критична.
Ние обучихме системата да определя периодите на притежание. За домейни това е относително лесно, тъй като в whois често са посочени дати на начало и изтичане на регистрацията и, когато има пълна история на промените в whois, определянето на периодите е просто. Когато срокът на регистрация на домейна не е изтекъл, но управлението е било прехвърлено на други собственици, също може да се проследи. За SSL сертификатите този проблем не съществува, тъй като той се издава веднъж, не се подновява и не се прехвърля. Но на самоподписаните сертификати не може да се вярва на датите, посочени в срока на валидност на сертификата, защото можете да генерирате SSL сертификат днес и да посочите дата на начало на валидност от 2010 година. Най-трудно е да се определят периодите на притежание за сървъри, тъй като датите и сроковете на наемане съществуват само при хостинг доставчиците. За да определим периода на притежание на сървера, започнахме да използваме резултатите от сканирането на портовете и създаването на отпечатъци на активните услуги на портовете. На база на тази информация можем доста точно да кажем, кога е сменен собственикът на сървера.

Няколко връзки. Обяснение. Сега не е проблем дори безплатно да получите списък с домейни, в whois на които е посочен определен имейл адрес, или да разберете всички домейни, свързани с определен IP адрес. Но когато става дума за хакери, които правят всичко възможно, за да бъдат трудни за проследяване, са нужни допълнителни "трикове", които да позволят намирането на нови свойства и изграждането на нови връзки.
Проведохме много време в проучване на начините за извличане на данни, които не са достъпни по обичаен начин. Не можем да опишем как точно работи това по разбираеми причини, но при определени обстоятелства, хакерите допускат грешки при регистрация на домейни или наемане и настройка на сървъри, които позволяват да се разкрият адреси на електронна поща, псевдоними на хакери и бекенд адреси. Колкото повече връзки извлечете, толкова по-точно може да се изградят графовете.

Как работи нашият граф

За да започнете да използвате мрежов граф, трябва да въведете в полето за търсене домейн, IP адрес, имейл или отпечатък на 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, известен още като 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