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

Не се взема предвид интервалът на притежание на сървъра и домейна. Обяснение. Срокът на регистрация на „лоши домейни“ рано или късно изтича и те отново се купуват за злонамерени или легитимни цели. Дори и при 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 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