Group-IB-eksperter har undersøgt sager relateret til phishing, botnets, svigagtige transaktioner og kriminelle hackergrupper, og har brugt grafanalyse i mange år til at identificere forskellige former for forbindelser. Forskellige cases har deres egne datasæt, deres egne algoritmer til at identificere forbindelser og grænseflader, der er skræddersyet til specifikke opgaver. Alle disse værktøjer blev internt udviklet af Group-IB og var kun tilgængelige for vores medarbejdere.

Grafanalyse af netværksinfrastruktur (netværksgraf) blev det første interne værktøj, som vi indbyggede i alle virksomhedens offentlige produkter. Før vi lavede vores netværksgraf, analyserede vi mange lignende udviklinger på markedet og fandt ikke et eneste produkt, der opfyldte vores egne behov. I denne artikel vil vi tale om, hvordan vi oprettede netværksgrafen, hvordan vi bruger den, og hvilke vanskeligheder vi stødte på.

Dmitry Volkov, CTO Group-IB og chef for cyberefterretninger

Hvad kan Group-IB-netværksgrafen?

Undersøgelser

Siden grundlæggelsen af ​​Group-IB i 2003 og frem til i dag, har identificering, udnævnelse og retsforfølgning af cyberkriminelle været en topprioritet i vores arbejde. Ikke en eneste undersøgelse af cyberangreb var komplet uden at analysere angribernes netværksinfrastruktur. Allerede i begyndelsen af ​​vores rejse var det et ret omhyggeligt "manuelt arbejde" at søge efter relationer, der kunne hjælpe med at identificere kriminelle: oplysninger om domænenavne, IP-adresser, digitale fingeraftryk fra servere osv.

De fleste angribere forsøger at agere så anonymt som muligt på netværket. Men som alle mennesker laver de fejl. Hovedmålet med en sådan analyse er at finde "hvide" eller "grå" historiske projekter af angribere, der har krydsninger med den ondsindede infrastruktur, der bruges i den aktuelle hændelse, som vi efterforsker. Hvis det er muligt at opdage "hvide projekter", bliver det som regel en triviel opgave at finde angriberen. I tilfælde af "grå" tager søgningen mere tid og kræfter, da deres ejere forsøger at anonymisere eller skjule registreringsdata, men chancerne forbliver ret høje. Som regel er angriberne i begyndelsen af ​​deres kriminelle aktiviteter mindre opmærksomme på deres egen sikkerhed og laver flere fejl, så jo dybere vi kan dykke ned i historien, jo større er chancerne for en vellykket efterforskning. Derfor er en netværksgraf med en god historie et yderst vigtigt element i sådan en undersøgelse. Kort sagt, jo dybere historiske data en virksomhed har, jo bedre er dens graf. Lad os sige, at en 5-årig historie kan hjælpe med at opklare, betinget, 1-2 ud af 10 forbrydelser, og en 15-årig historie giver en chance for at opklare alle ti.

Opdagelse af phishing og svindel

Hver gang vi modtager et mistænkeligt link til en phishing, svigagtig eller piratkopieret ressource, bygger vi automatisk en graf over relaterede netværksressourcer og tjekker alle fundne værter for lignende indhold. Dette giver dig mulighed for at finde både gamle phishing-sider, der var aktive, men ukendte, samt helt nye, der er forberedt på fremtidige angreb, men endnu ikke er brugt. Et elementært eksempel, der forekommer ret ofte: vi fandt et phishing-sted på en server med kun 5 websteder. Ved at kontrollere hver af dem finder vi phishing-indhold på andre websteder, hvilket betyder, at vi kan blokere 5 i stedet for 1.

Søg efter backends

Denne proces er nødvendig for at bestemme, hvor den ondsindede server rent faktisk befinder sig.
99 % af kortbutikker, hackerfora, mange phishing-ressourcer og andre ondsindede servere er skjult bag både deres egne proxyservere og proxyer til legitime tjenester, for eksempel Cloudflare. Viden om den rigtige backend er meget vigtig for undersøgelser: Hostingudbyderen, hvorfra serveren kan beslaglægges, bliver kendt, og det bliver muligt at opbygge forbindelser med andre ondsindede projekter.

For eksempel har du et phishing-sted til indsamling af bankkortdata, der omdannes til IP-adressen 11.11.11.11, og en cardshop-adresse, der omdannes til IP-adressen 22.22.22.22. Under analysen kan det vise sig, at både phishing-siden og cardshop har en fælles backend IP-adresse, for eksempel 33.33.33.33. Denne viden giver os mulighed for at opbygge en forbindelse mellem phishing-angreb og en kortbutik, hvor bankkortdata kan sælges.

Hændelseskorrelation

Når du har to forskellige triggere (lad os sige på en IDS) med forskellig malware og forskellige servere til at kontrollere angrebet, vil du behandle dem som to uafhængige hændelser. Men hvis der er en god sammenhæng mellem ondsindede infrastrukturer, så bliver det indlysende, at der ikke er tale om forskellige angreb, men stadier af et, mere komplekst flertrinsangreb. Og hvis en af ​​begivenhederne allerede er tilskrevet en gruppe af angribere, så kan den anden også tilskrives den samme gruppe. Naturligvis er tilskrivningsprocessen meget mere kompleks, så behandl dette som et simpelt eksempel.

Indikator berigelse

Vi vil ikke være meget opmærksomme på dette, da dette er det mest almindelige scenarie for brug af grafer i cybersikkerhed: du giver en indikator som input, og som et output får du en række relaterede indikatorer.

Identifikation af mønstre

At identificere mønstre er afgørende for effektiv jagt. Grafer giver dig mulighed for ikke kun at finde relaterede elementer, men også at identificere fælles egenskaber, der er karakteristiske for en bestemt gruppe af hackere. Kendskab til sådanne unikke egenskaber giver dig mulighed for at genkende angriberens infrastruktur selv på forberedelsesstadiet og uden beviser, der bekræfter angrebet, såsom phishing-e-mails eller malware.

Hvorfor lavede vi vores egen netværksgraf?

Igen kiggede vi på løsninger fra forskellige leverandører, før vi kom til den konklusion, at vi skulle udvikle vores eget værktøj, der kunne noget, som intet eksisterende produkt kunne. Det tog flere år at skabe det, hvor vi fuldstændig ændrede det flere gange. Men på trods af den lange udviklingsperiode har vi endnu ikke fundet en eneste analog, der ville tilfredsstille vores krav. Ved at bruge vores eget produkt var vi til sidst i stand til at løse næsten alle de problemer, vi opdagede i eksisterende netværksgrafer. Nedenfor vil vi overveje disse problemer i detaljer:

problem
beslutning

Mangel på en udbyder med forskellige samlinger af data: domæner, passiv DNS, passiv SSL, DNS-poster, åbne porte, kørende tjenester på porte, filer, der interagerer med domænenavne og IP-adresser. Forklaring. Typisk leverer udbydere separate typer data, og for at få det fulde billede skal du købe abonnementer fra alle. Alligevel er det ikke altid muligt at få alle data: Nogle passive SSL-udbydere leverer kun data om certifikater udstedt af betroede CA'er, og deres dækning af selvsignerede certifikater er ekstremt dårlig. Andre leverer også data ved hjælp af selvsignerede certifikater, men indsamler det kun fra standardporte.
Vi har selv samlet alle ovenstående samlinger. For at indsamle data om SSL-certifikater skrev vi for eksempel vores egen tjeneste, der indsamler dem både fra betroede CA'er og ved at scanne hele IPv4-rummet. Certifikater blev indsamlet ikke kun fra IP, men også fra alle domæner og underdomæner fra vores database: hvis du har domænet example.com og dets underdomæne www.example.com og de løser alle til IP 1.1.1.1, så når du forsøger at få et SSL-certifikat fra port 443 på en IP, domæne og dets underdomæne, kan du få tre forskellige resultater. For at indsamle data om åbne porte og kørende tjenester var vi nødt til at oprette vores eget distribuerede scanningssystem, fordi andre tjenester ofte havde IP-adresserne på deres scanningsservere på "sorte lister." Vores scanningsservere ender også på sortlister, men resultatet af at opdage de tjenester, vi har brug for, er højere end dem, der blot scanner så mange porte som muligt og sælger adgang til disse data.

Manglende adgang til hele databasen med historiske optegnelser. Forklaring. Enhver normal leverandør har en god akkumuleret historie, men af ​​naturlige årsager kunne vi som kunde ikke få adgang til alle historiske data. De der. Du kan få hele historikken for en enkelt post, for eksempel efter domæne eller IP-adresse, men du kan ikke se historikken for alt - og uden denne kan du ikke se det fulde billede.
For at indsamle så mange historiske optegnelser om domæner som muligt, købte vi forskellige databaser, analyserede mange åbne ressourcer, der havde denne historie (det er godt, at der var mange af dem), og forhandlede med domænenavnsregistratorer. Alle opdateringer til vores egne samlinger opbevares naturligvis med en komplet revisionshistorik.

Alle eksisterende løsninger giver dig mulighed for at bygge en graf manuelt. Forklaring. Lad os sige, at du har købt en masse abonnementer fra alle mulige dataudbydere (normalt kaldet "berigere"). Når du skal bygge en graf, giver du "hænder" kommandoen til at bygge fra det ønskede forbindelseselement, vælg derefter de nødvendige fra de elementer, der vises og giver kommandoen til at fuldføre forbindelserne fra dem, og så videre. I dette tilfælde ligger ansvaret for, hvor godt grafen vil blive konstrueret, helt hos personen.
Vi lavede automatisk konstruktion af grafer. De der. hvis du skal bygge en graf, så bygges forbindelser fra det første element automatisk, derefter fra alle efterfølgende også. Specialisten angiver kun den dybde, hvor grafen skal bygges. Processen med automatisk at udfylde grafer er enkel, men andre leverandører implementerer den ikke, fordi den producerer et stort antal irrelevante resultater, og vi var også nødt til at tage højde for denne ulempe (se nedenfor).

Mange irrelevante resultater er et problem med alle netværkselementgrafer. Forklaring. For eksempel er et "dårligt domæne" (deltaget i et angreb) forbundet med en server, der har 10 andre domæner tilknyttet i løbet af de sidste 500 år. Når man manuelt tilføjer eller automatisk konstruerer en graf, bør alle disse 500 domæner også vises på grafen, selvom de ikke er relateret til angrebet. Eller du tjekker for eksempel IP-indikatoren fra leverandørens sikkerhedsrapport. Typisk frigives sådanne rapporter med en betydelig forsinkelse og strækker sig ofte over et år eller mere. På det tidspunkt, hvor du læser rapporten, er serveren med denne IP-adresse højst sandsynligt allerede udlejet til andre personer med andre forbindelser, og opbygning af en graf vil igen resultere i, at du får irrelevante resultater.
Vi trænede systemet til at identificere irrelevante elementer ved hjælp af den samme logik, som vores eksperter gjorde manuelt. For eksempel tjekker du et dårligt domæne example.com, som nu løses til IP 11.11.11.11, og for en måned siden - til IP 22.22.22.22. Ud over domænet example.com er IP 11.11.11.11 også forbundet med example.ru, og IP 22.22.22.22 er forbundet med 25 tusinde andre domæner. Systemet forstår, ligesom en person, at 11.11.11.11 højst sandsynligt er en dedikeret server, og da domænet example.ru i stavemåde ligner example.com, så er de med stor sandsynlighed forbundet og burde være på kurve; men IP 22.22.22.22 tilhører delt hosting, så alle dets domæner behøver ikke at være inkluderet i grafen, medmindre der er andre forbindelser, der viser, at et af disse 25 tusinde domæner også skal inkluderes (f.eks. example.net) . Før systemet forstår, at forbindelser skal brydes, og nogle elementer ikke flyttes til grafen, tager det hensyn til mange egenskaber ved de elementer og klynger, som disse elementer er kombineret i, samt styrken af ​​de nuværende forbindelser. For eksempel, hvis vi har en lille klynge (50 elementer) på grafen, som inkluderer et dårligt domæne, og en anden stor klynge (5 tusinde elementer), og begge klynger er forbundet med en forbindelse (linje) med meget lav styrke (vægt) , så vil en sådan forbindelse blive brudt, og elementer fra den store klynge vil blive fjernet. Men hvis der er mange forbindelser mellem små og store klynger, og deres styrke gradvist øges, vil forbindelsen i dette tilfælde ikke blive brudt, og de nødvendige elementer fra begge klynger forbliver på grafen.

Server- og domæneejerskabsintervallet tages ikke i betragtning. Forklaring. "Dårlige domæner" vil før eller siden udløbe og blive købt igen til ondsindede eller legitime formål. Selv skudsikre hostingservere udlejes til forskellige hackere, så det er vigtigt at kende og tage højde for intervallet, hvor et bestemt domæne/server var under kontrol af én ejer. Vi støder ofte på en situation, hvor en server med IP 11.11.11.11 nu bruges som C&C for en bankbot, og for 2 måneder siden blev den kontrolleret af Ransomware. Hvis vi bygger en forbindelse uden at tage hensyn til ejerskabsintervaller, vil det se ud som om, der er en forbindelse mellem ejerne af bankbotnettet og ransomwaren, selvom der faktisk ikke er nogen. I vores arbejde er en sådan fejl kritisk.
Vi lærte systemet at bestemme ejerskabsintervaller. For domæner er dette relativt enkelt, fordi whois ofte indeholder start- og udløbsdatoer for registrering, og når der er en komplet historik over whois-ændringer, er det nemt at bestemme intervallerne. Når et domænes registrering ikke er udløbet, men dets administration er blevet overført til andre ejere, kan det også spores. Der er ikke noget sådant problem for SSL-certifikater, fordi de udstedes én gang og ikke fornyes eller overføres. Men med selvsignerede certifikater kan du ikke stole på de datoer, der er angivet i certifikatets gyldighedsperiode, fordi du kan generere et SSL-certifikat i dag og angive certifikatets startdato fra 2010. Det sværeste er at bestemme ejerskabsintervallerne for servere, fordi kun hostingudbydere har datoer og lejeperioder. For at bestemme serverens ejerskabsperiode begyndte vi at bruge resultaterne af portscanning og oprettelse af fingeraftryk af kørende tjenester på porte. Ved at bruge disse oplysninger kan vi ret præcist sige, hvornår serverens ejer skiftede.

Få forbindelser. Forklaring. I dag er det ikke engang et problem at få en gratis liste over domæner, hvis whois indeholder en specifik e-mailadresse, eller at finde ud af alle domæner, der var knyttet til en specifik IP-adresse. Men når det kommer til hackere, der gør deres bedste for at være svære at spore, har vi brug for yderligere tricks til at finde nye egenskaber og bygge nye forbindelser.
Vi brugte meget tid på at undersøge, hvordan vi kunne udtrække data, der ikke var tilgængelige på en konventionel måde. Vi kan ikke beskrive her, hvordan det fungerer af indlysende årsager, men under visse omstændigheder begår hackere, når de registrerer domæner eller lejer og opsætter servere, fejl, der gør det muligt for dem at finde ud af e-mailadresser, hacker-aliaser og backend-adresser. Jo flere forbindelser du udtrækker, jo mere nøjagtige grafer kan du bygge.

Hvordan vores graf fungerer

For at begynde at bruge netværksgrafen skal du indtaste domænet, IP-adressen, e-mailen eller SSL-certifikatets fingeraftryk i søgelinjen. Der er tre forhold, som analytikeren kan kontrollere: tid, trindybde og clearing.

Time

Tid – dato eller interval, hvor det søgte element blev brugt til ondsindede formål. Hvis du ikke angiver denne parameter, vil systemet selv bestemme det sidste ejerskabsinterval for denne ressource. Eksempelvis offentliggjorde Eset den 11. juli rapport om, hvordan Buhtrap bruger 0-dages udnyttelse til cyberspionage. Der er 6 indikatorer i slutningen af ​​rapporten. En af dem, secure-telemetry[.]net, blev genregistreret den 16. juli. Derfor, hvis du bygger en graf efter den 16. juli, vil du få irrelevante resultater. Men hvis du angiver, at dette domæne blev brugt før denne dato, så inkluderer grafen 126 nye domæner, 69 IP-adresser, der ikke er angivet i Eset-rapporten:

• ukrfreshnews[.]com
• unian-search[.]com
• vesti-verden[.]info
• runewsmeta[.]com
• foxnewsmeta[.]biz
• sobesednik-meta[.]info
• rian-ua[.]net
• etc.

Ud over netværksindikatorer finder vi straks forbindelser med ondsindede filer, der havde forbindelser til denne infrastruktur og tags, der fortæller os, at Meterpreter og AZORult blev brugt.

Det fantastiske er, at du får dette resultat inden for et sekund, og du behøver ikke længere bruge dage på at analysere dataene. Selvfølgelig reducerer denne tilgang nogle gange betydeligt tiden til undersøgelser, hvilket ofte er kritisk.

Antallet af trin eller rekursionsdybde, som grafen vil blive bygget med

Som standard er dybden 3. Det betyder, at alle direkte relaterede elementer vil blive fundet fra det ønskede element, derefter vil der blive bygget nye forbindelser fra hvert nyt element til andre elementer, og nye elementer vil blive oprettet ud fra de nye elementer fra sidst trin.

Lad os tage et eksempel, der ikke er relateret til APT og 0-dages udnyttelser. For nylig blev en interessant sag om svindel relateret til kryptovalutaer beskrevet på Habré. Rapporten nævner domænet themcx[.]co, der bruges af svindlere til at hoste et websted, der foregiver at være en Miner Coin Exchange og telefonopslag[.]xyz for at tiltrække trafik.

Det fremgår tydeligt af beskrivelsen, at ordningen kræver en ret stor infrastruktur for at tiltrække trafik til svigagtige ressourcer. Vi besluttede at se på denne infrastruktur ved at bygge en graf i 4 trin. Outputtet var en graf med 230 domæner og 39 IP-adresser. Dernæst opdeler vi domæner i 2 kategorier: dem, der ligner tjenester til at arbejde med kryptovalutaer, og dem, der er beregnet til at drive trafik gennem telefonverifikationstjenester:

Relateret til cryptocurrency
Tilknyttet telefonstansetjenester

møntholder[.]cc
opkalds-record[.]site.

mcxwallet[.]co
telefon-optegnelser[.]plads

btcnoise[.]com
fone-afslør[.]xyz

kryptominer[.]watch
nummer-afdækning[.]info

Очистка

Som standard er "Graph Cleanup" muligheden aktiveret, og alle irrelevante elementer vil blive fjernet fra grafen. Det blev i øvrigt brugt i alle tidligere eksempler. Jeg forudser et naturligt spørgsmål: hvordan kan vi sikre, at noget vigtigt ikke bliver slettet? Jeg vil svare: for analytikere, der kan lide at bygge grafer i hånden, kan automatiseret rengøring deaktiveres, og antallet af trin kan vælges = 1. Dernæst vil analytikeren være i stand til at færdiggøre grafen fra de elementer, han har brug for, og fjerne elementer fra grafen, der er irrelevant for opgaven.

Allerede på grafen bliver historien om ændringer i whois, DNS samt åbne porte og tjenester, der kører på dem, tilgængelig for analytikeren.

Finansielt phishing

Vi undersøgte aktiviteterne i en APT-gruppe, som i flere år udførte phishing-angreb mod kunder fra forskellige banker i forskellige regioner. Et karakteristisk træk ved denne gruppe var registreringen af ​​domæner meget lig navnene på rigtige banker, og de fleste af phishing-siderne havde det samme design, de eneste forskelle var i navnene på bankerne og deres logoer.

I dette tilfælde hjalp automatiseret grafanalyse os meget. Ved at tage et af deres domæner - lloydsbnk-uk[.]com, byggede vi på få sekunder en graf med en dybde på 3 trin, som identificerede mere end 250 ondsindede domæner, som er blevet brugt af denne gruppe siden 2015 og fortsætter med at blive brugt . Nogle af disse domæner er allerede blevet købt af banker, men historiske optegnelser viser, at de tidligere var registreret til angribere.

For overskuelighed viser figuren en graf med en dybde på 2 trin.

Det er bemærkelsesværdigt, at angriberne allerede i 2019 ændrede deres taktik noget og begyndte at registrere ikke kun bankernes domæner til hosting af web-phishing, men også domænerne fra forskellige konsulentfirmaer til at sende phishing-e-mails. For eksempel domænerne swift-department.com, saudconsultancy.com, vbgrigoryanpartners.com.

Kobolt bande

I december 2018 sendte hackergruppen Cobalt, med speciale i målrettede angreb på banker, en mailkampagne på vegne af Kasakhstans nationalbank.

Brevene indeholdt links til hXXps://nationalbank.bz/Doc/Prikaz.doc. Det downloadede dokument indeholdt en makro, der startede Powershell, som ville forsøge at indlæse og udføre filen fra hXXp://wateroilclub.com/file/dwm.exe i %Temp%einmrmdmy.exe. Filen %Temp%einmrmdmy.exe aka dwm.exe er en CobInt stager, der er konfigureret til at interagere med serveren hXXp://admvmsopp.com/rilruietguadvtoefmuy.

Forestil dig, at du ikke kan modtage disse phishing-e-mails og udføre en fuld analyse af de ondsindede filer. Grafen for det ondsindede domæne nationalbank[.]bz viser øjeblikkeligt forbindelser med andre ondsindede domæner, tilskriver det en gruppe og viser, hvilke filer der blev brugt i angrebet.

Lad os tage IP-adressen 46.173.219[.]152 fra denne graf og bygge en graf ud fra den i én omgang og slå rengøring fra. Der er 40 domæner tilknyttet, for eksempel bl0ckchain[.]ug
paypal.co.uk.qlg6[.]pw
cryptoelips[.]com

At dømme efter domænenavnene ser det ud til, at de bruges i svigagtige ordninger, men rengøringsalgoritmen indså, at de ikke var relateret til dette angreb og satte dem ikke på grafen, hvilket i høj grad forenkler processen med analyse og tilskrivning.

Hvis du genopbygger grafen ved hjælp af nationalbank[.]bz, men deaktiverer grafrensningsalgoritmen, vil den indeholde mere end 500 elementer, hvoraf de fleste ikke har noget at gøre med Cobalt-gruppen eller deres angreb. Et eksempel på, hvordan en sådan graf ser ud, er givet nedenfor:

Konklusion

Efter flere års finjustering, test i reelle undersøgelser, trusselsforskning og jagt på angribere, lykkedes det ikke kun at skabe et unikt værktøj, men også at ændre holdningen hos eksperter i virksomheden til det. I første omgang ønsker tekniske eksperter fuldstændig kontrol over grafkonstruktionsprocessen. Det var ekstremt svært at overbevise dem om, at automatisk grafkonstruktion kunne gøre dette bedre end en person med mange års erfaring. Alt blev bestemt af tid og flere "manuelle" kontroller af resultaterne af, hvad grafen producerede. Nu stoler vores eksperter ikke kun på systemet, men bruger også de resultater, det opnår i deres daglige arbejde. Denne teknologi virker inde i hvert af vores systemer og giver os mulighed for bedre at identificere trusler af enhver type. Interfacet til manuel grafanalyse er indbygget i alle Group-IB-produkter og udvider mulighederne for cyberkriminalitetsjagt markant. Dette bekræftes af analytikeranmeldelser fra vores kunder. Og vi fortsætter til gengæld med at berige grafen med data og arbejde på nye algoritmer ved hjælp af kunstig intelligens til at skabe den mest nøjagtige netværksgraf.

Kilde: www.habr.com