Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen

Group-IB-eksperter har undersøkt saker relatert til phishing, botnett, uredelige transaksjoner og kriminelle hackergrupper, og har brukt grafanalyse i mange år for å identifisere ulike typer forbindelser. Ulike tilfeller har egne datasett, egne algoritmer for å identifisere forbindelser og grensesnitt skreddersydd for spesifikke oppgaver. Alle disse verktøyene ble internt utviklet av Group-IB og var kun tilgjengelig for våre ansatte.

Grafanalyse av nettverksinfrastruktur (nettverksgraf) ble det første interne verktøyet som vi bygget inn i alle selskapets offentlige produkter. Før vi laget nettverksgrafen vår, analyserte vi mange lignende utviklinger på markedet og fant ikke et eneste produkt som tilfredsstilte våre egne behov. I denne artikkelen vil vi snakke om hvordan vi laget nettverksgrafen, hvordan vi bruker den og hvilke vanskeligheter vi møtte.

Dmitrij Volkov, CTO Group-IB og leder for cyberintelligens

Hva kan Group-IB-nettverksgrafen gjøre?

Undersøkelser

Siden grunnleggelsen av Group-IB i 2003 og frem til i dag, har identifisering, utpeking og rettsliggjøring av nettkriminelle vært en toppprioritet i vårt arbeid. Ikke en eneste etterforskning av nettangrep var fullført uten å analysere nettverksinfrastrukturen til angriperne. Helt i begynnelsen av reisen vår var det et ganske møysommelig "manuelt arbeid" å søke etter relasjoner som kunne hjelpe til med å identifisere kriminelle: informasjon om domenenavn, IP-adresser, digitale fingeravtrykk fra servere, etc.

De fleste angripere prøver å opptre så anonymt som mulig på nettverket. Men som alle mennesker gjør de feil. Hovedmålet med en slik analyse er å finne "hvite" eller "grå" historiske prosjekter av angripere som har skjæringspunkter med den skadelige infrastrukturen som brukes i den aktuelle hendelsen som vi etterforsker. Hvis det er mulig å oppdage "hvite prosjekter", blir det som regel en triviell oppgave å finne angriperen. Når det gjelder «grå», tar søket mer tid og krefter, siden eierne deres prøver å anonymisere eller skjule registreringsdata, men sjansene er fortsatt ganske høye. Som regel, i begynnelsen av sine kriminelle aktiviteter, tar angripere mindre oppmerksomhet til sin egen sikkerhet og gjør flere feil, så jo dypere vi kan dykke ned i historien, jo større er sjansene for en vellykket etterforskning. Derfor er en nettverksgraf med god historikk et ekstremt viktig element i en slik undersøkelse. Enkelt sagt, jo dypere historiske data et selskap har, jo bedre er grafen. La oss si at en 5-årig historie kan bidra til å løse, betinget, 1-2 av 10 forbrytelser, og en 15-årig historie gir en sjanse til å løse alle ti.

Oppdagelse av phishing og svindel

Hver gang vi mottar en mistenkelig kobling til en phishing, svindel eller piratkopiert ressurs, bygger vi automatisk en graf over relaterte nettverksressurser og sjekker alle funnet verter for lignende innhold. Dette lar deg finne både gamle phishing-sider som var aktive, men ukjente, samt helt nye som er forberedt på fremtidige angrep, men som ennå ikke er tatt i bruk. Et elementært eksempel som forekommer ganske ofte: vi fant et phishing-nettsted på en server med bare 5 nettsteder. Ved å sjekke hver av dem finner vi phishing-innhold på andre nettsteder, noe som betyr at vi kan blokkere 5 i stedet for 1.

Søk etter backends

Denne prosessen er nødvendig for å finne ut hvor den ondsinnede serveren faktisk befinner seg.
99 % av kortbutikker, hackerfora, mange phishing-ressurser og andre ondsinnede servere er skjult bak både deres egne proxy-servere og proxy-tjenere til legitime tjenester, for eksempel Cloudflare. Kunnskap om den virkelige backend er svært viktig for undersøkelser: vertsleverandøren som serveren kan beslaglegges fra blir kjent, og det blir mulig å bygge forbindelser med andre ondsinnede prosjekter.

For eksempel har du et phishing-nettsted for innsamling av bankkortdata som går til IP-adressen 11.11.11.11, og en kortbutikkadresse som går til IP-adressen 22.22.22.22. Under analysen kan det vise seg at både phishing-siden og cardshop har en felles backend IP-adresse, for eksempel 33.33.33.33. Denne kunnskapen lar oss bygge en forbindelse mellom phishing-angrep og en kortbutikk hvor bankkortdata kan selges.

Hendelseskorrelasjon

Når du har to forskjellige triggere (la oss si på en IDS) med forskjellig malware og forskjellige servere for å kontrollere angrepet, vil du behandle dem som to uavhengige hendelser. Men hvis det er en god sammenheng mellom ondsinnet infrastruktur, så blir det åpenbart at dette ikke er forskjellige angrep, men stadier av ett, mer komplekst flertrinnsangrep. Og hvis en av hendelsene allerede er tilskrevet en gruppe angripere, kan den andre også tilskrives den samme gruppen. Selvfølgelig er attribusjonsprosessen mye mer kompleks, så betrakt dette som et enkelt eksempel.

Indikatorberikelse

Vi vil ikke betale mye oppmerksomhet til dette, siden dette er det vanligste scenariet for bruk av grafer i cybersikkerhet: du gir én indikator som input, og som en utgang får du en rekke relaterte indikatorer.

Identifisere mønstre

Å identifisere mønstre er avgjørende for effektiv jakt. Grafer lar deg ikke bare finne relaterte elementer, men også identifisere vanlige egenskaper som er karakteristiske for en bestemt gruppe hackere. Kunnskap om slike unike egenskaper lar deg gjenkjenne angriperens infrastruktur selv på forberedelsesstadiet og uten bevis som bekrefter angrepet, for eksempel phishing-e-post eller skadelig programvare.

Hvorfor laget vi vår egen nettverksgraf?

Igjen så vi på løsninger fra forskjellige leverandører før vi kom til den konklusjonen at vi trengte å utvikle vårt eget verktøy som kunne gjøre noe som ingen eksisterende produkter kunne gjøre. Det tok flere år å lage den, og vi endret den fullstendig flere ganger. Men til tross for den lange utviklingsperioden, har vi ennå ikke funnet en eneste analog som vil tilfredsstille kravene våre. Ved å bruke vårt eget produkt klarte vi til slutt å løse nesten alle problemene vi oppdaget i eksisterende nettverksgrafer. Nedenfor vil vi vurdere disse problemene i detalj:

problem
beslutning

Mangel på en leverandør med ulike samlinger av data: domener, passiv DNS, passiv SSL, DNS-poster, åpne porter, kjører tjenester på porter, filer som samhandler med domenenavn og IP-adresser. Forklaring. Vanligvis gir leverandører separate typer data, og for å få hele bildet må du kjøpe abonnementer fra alle. Likevel er det ikke alltid mulig å få tak i alle dataene: Noen passive SSL-leverandører gir kun data om sertifikater utstedt av klarerte CAer, og deres dekning av selvsignerte sertifikater er ekstremt dårlig. Andre gir også data ved å bruke selvsignerte sertifikater, men samler det bare inn fra standardporter.
Vi har samlet alle de ovennevnte samlingene selv. For å samle inn data om SSL-sertifikater, skrev vi for eksempel vår egen tjeneste som samler dem både fra klarerte CAer og ved å skanne hele IPv4-området. Sertifikater ble samlet inn ikke bare fra IP, men også fra alle domener og underdomener fra databasen vår: hvis du har domenet example.com og dets underdomene www.example.com og de løser seg alle til IP 1.1.1.1, så når du prøver å få et SSL-sertifikat fra port 443 på en IP, domene og dets underdomene, kan du få tre forskjellige resultater. For å samle inn data om åpne porter og kjørende tjenester, måtte vi lage vårt eget distribuerte skannesystem, fordi andre tjenester ofte hadde IP-adressene til skanneserverne sine på "svartelister." Skanningsserverne våre havner også på svartelister, men resultatet av å oppdage tjenestene vi trenger er høyere enn for de som rett og slett skanner så mange porter som mulig og selger tilgang til disse dataene.

Mangel på tilgang til hele databasen med historiske poster. Forklaring. Hver normal leverandør har en god akkumulert historikk, men av naturlige årsaker kunne vi som oppdragsgiver ikke få tilgang til alle historiske data. De. Du kan få hele historikken for en enkelt post, for eksempel etter domene eller IP-adresse, men du kan ikke se historikken til alt - og uten dette kan du ikke se hele bildet.
For å samle så mange historiske poster på domener som mulig, kjøpte vi forskjellige databaser, analyserte mange åpne ressurser som hadde denne historien (det er bra at det var mange av dem), og forhandlet med domenenavnregistratorer. Alle oppdateringer til våre egne samlinger holdes selvfølgelig med full revisjonshistorikk.

Alle eksisterende løsninger lar deg bygge en graf manuelt. Forklaring. La oss si at du har kjøpt mange abonnementer fra alle mulige dataleverandører (vanligvis kalt «berikere»). Når du trenger å bygge en graf, gir du "hender" kommandoen om å bygge fra ønsket koblingselement, velg deretter de nødvendige fra elementene som vises og gir kommandoen for å fullføre koblingene fra dem, og så videre. I dette tilfellet ligger ansvaret for hvor godt grafen vil bli konstruert helt hos personen.
Vi laget automatisk konstruksjon av grafer. De. Hvis du trenger å bygge en graf, bygges koblinger fra det første elementet automatisk, deretter fra alle påfølgende også. Spesialisten angir kun dybden som grafen skal bygges på. Prosessen med å automatisk fullføre grafer er enkel, men andre leverandører implementerer den ikke fordi den gir et stort antall irrelevante resultater, og vi måtte også ta hensyn til denne ulempen (se nedenfor).

Mange irrelevante resultater er et problem med alle nettverkselementgrafer. Forklaring. For eksempel er et "dårlig domene" (deltatt i et angrep) assosiert med en server som har 10 andre domener knyttet til seg i løpet av de siste 500 årene. Når du legger til eller automatisk konstruerer en graf manuelt, skal alle disse 500 domenene også vises på grafen, selv om de ikke er relatert til angrepet. Eller du sjekker for eksempel IP-indikatoren fra leverandørens sikkerhetsrapport. Vanligvis utgis slike rapporter med betydelig forsinkelse og strekker seg ofte over et år eller mer. Mest sannsynlig, på det tidspunktet du leser rapporten, er serveren med denne IP-adressen allerede leid ut til andre personer med andre forbindelser, og å bygge en graf vil igjen føre til at du får irrelevante resultater.
Vi trente systemet til å identifisere irrelevante elementer ved å bruke samme logikk som ekspertene våre gjorde manuelt. For eksempel sjekker du et dårlig domene example.com, som nå løses til IP 11.11.11.11, og for en måned siden - til IP 22.22.22.22. I tillegg til domenet example.com, er IP 11.11.11.11 også assosiert med example.ru, og IP 22.22.22.22 er assosiert med 25 tusen andre domener. Systemet, som en person, forstår at 11.11.11.11 mest sannsynlig er en dedikert server, og siden example.ru-domenet er liknende stavemåte som example.com, så er de med stor sannsynlighet koblet til og bør være på kurve; men IP 22.22.22.22 tilhører delt hosting, så alle domenene trenger ikke inkluderes i grafen med mindre det er andre forbindelser som viser at ett av disse 25 tusen domenene også må inkluderes (for eksempel eksempel.net) . Før systemet forstår at koblinger må brytes og noen elementer ikke flyttes til grafen, tar det hensyn til mange egenskaper til elementene og klynger som disse elementene er kombinert i, samt styrken til de nåværende koblingene. For eksempel, hvis vi har en liten klynge (50 elementer) på grafen, som inkluderer et dårlig domene, og en annen stor klynge (5 tusen elementer) og begge klyngene er forbundet med en forbindelse (linje) med veldig lav styrke (vekt) , da vil en slik forbindelse bli brutt og elementer fra den store klyngen fjernes. Men hvis det er mange forbindelser mellom små og store klynger og deres styrke gradvis øker, vil i dette tilfellet ikke forbindelsen bli brutt, og de nødvendige elementene fra begge klynger vil forbli på grafen.

Server- og domeneeierskapsintervallet er ikke tatt i betraktning. Forklaring. "Dårlige domener" vil før eller siden utløpe og bli kjøpt på nytt for ondsinnede eller legitime formål. Selv skuddsikre hostingservere leies ut til forskjellige hackere, så det er viktig å vite og ta hensyn til intervallet da et bestemt domene/server var under kontroll av én eier. Vi møter ofte en situasjon der en server med IP 11.11.11.11 nå brukes som en C&C for en bankbot, og for 2 måneder siden ble den kontrollert av Ransomware. Hvis vi bygger en forbindelse uten å ta hensyn til eierskapsintervaller, vil det se ut som det er en forbindelse mellom eierne av bankbotnettet og løsepengevaren, selv om det faktisk ikke er noen. I vårt arbeid er en slik feil kritisk.
Vi lærte systemet å bestemme eierskapsintervaller. For domener er dette relativt enkelt, fordi whois ofte inneholder start- og utløpsdatoer for registrering, og når det er en fullstendig historikk over whois-endringer, er det enkelt å bestemme intervallene. Når registreringen av et domene ikke har utløpt, men administrasjonen er overført til andre eiere, kan det også spores. Det er ikke noe slikt problem for SSL-sertifikater, fordi de utstedes én gang og ikke fornyes eller overføres. Men med selvsignerte sertifikater kan du ikke stole på datoene som er spesifisert i sertifikatets gyldighetsperiode, fordi du kan generere et SSL-sertifikat i dag, og spesifisere sertifikatets startdato fra 2010. Det vanskeligste er å bestemme eierintervallene for servere, fordi kun hostingleverandører har datoer og leieperioder. For å bestemme servereierskapsperioden begynte vi å bruke resultatene av portskanning og lage fingeravtrykk av kjørende tjenester på porter. Ved å bruke denne informasjonen kan vi ganske nøyaktig si når serverens eier endret seg.

Få forbindelser. Forklaring. I dag er det ikke engang et problem å få en gratis liste over domener hvis whois inneholder en spesifikk e-postadresse, eller å finne ut alle domenene som var knyttet til en spesifikk IP-adresse. Men når det kommer til hackere som gjør sitt beste for å være vanskelig å spore, trenger vi flere triks for å finne nye egenskaper og bygge nye forbindelser.
Vi brukte mye tid på å undersøke hvordan vi kunne trekke ut data som ikke var tilgjengelig på en konvensjonell måte. Vi kan ikke beskrive her hvordan det fungerer av åpenbare grunner, men under visse omstendigheter gjør hackere, når de registrerer domener eller leier og setter opp servere, feil som lar dem finne ut e-postadresser, hackeraliaser og backend-adresser. Jo flere forbindelser du trekker ut, jo mer nøyaktige grafer kan du bygge.

Hvordan grafen vår fungerer

For å begynne å bruke nettverksgrafen må du skrive inn domenet, IP-adressen, e-posten eller SSL-sertifikatets fingeravtrykk i søkefeltet. Det er tre forhold som analytikeren kan kontrollere: tid, trinndybde og rydding.

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen

tid

Tid – dato eller intervall da det søkte elementet ble brukt til ondsinnede formål. Hvis du ikke spesifiserer denne parameteren, vil systemet selv bestemme det siste eierskapsintervallet for denne ressursen. For eksempel publiserte Eset 11. juli rapportere om hvordan Buhtrap bruker 0-dagers utnyttelse til nettspionasje. Det er 6 indikatorer på slutten av rapporten. En av dem, secure-telemetry[.]net, ble registrert på nytt 16. juli. Derfor, hvis du bygger en graf etter 16. juli, vil du få irrelevante resultater. Men hvis du indikerer at dette domenet ble brukt før denne datoen, inkluderer grafen 126 nye domener, 69 IP-adresser som ikke er oppført i Eset-rapporten:

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

I tillegg til nettverksindikatorer finner vi umiddelbart forbindelser med ondsinnede filer som hadde forbindelser med denne infrastrukturen og tagger som forteller oss at Meterpreter og AZORult ble brukt.

Det fine er at du får dette resultatet i løpet av ett sekund, og du trenger ikke lenger bruke dager på å analysere dataene. Selvfølgelig reduserer denne tilnærmingen noen ganger tiden for undersøkelser betydelig, noe som ofte er kritisk.

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen

Antall trinn eller rekursjonsdybde som grafen skal bygges med

Som standard er dybden 3. Dette betyr at alle direkte relaterte elementer vil bli funnet fra det ønskede elementet, deretter vil nye forbindelser bygges fra hvert nytt element til andre elementer, og nye elementer vil bli opprettet fra de nye elementene fra sist steg.

La oss ta et eksempel som ikke er relatert til APT og 0-dagers utnyttelser. Nylig ble et interessant tilfelle av svindel knyttet til kryptovaluta beskrevet på Habré. Rapporten nevner domenet themcx[.]co, brukt av svindlere for å være vert for et nettsted som utgir seg for å være en Miner Coin Exchange og telefonoppslag[.]xyz for å tiltrekke seg trafikk.

Det fremgår tydelig av beskrivelsen at ordningen krever en ganske stor infrastruktur for å tiltrekke trafikk til uredelige ressurser. Vi bestemte oss for å se på denne infrastrukturen ved å bygge en graf i 4 trinn. Utgangen var en graf med 230 domener og 39 IP-adresser. Deretter deler vi domener i 2 kategorier: de som ligner tjenester for arbeid med kryptovalutaer og de som er ment å drive trafikk gjennom telefonverifiseringstjenester:

Relatert til kryptovaluta
Tilknyttet telefonstansetjenester

myntholder[.]cc
oppringer-post[.]side.

mcxwallet[.]co
telefon-poster[.]plass

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

kryptominer[.]watch
nummer-avdekke[.]info

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen

rengjøring

Som standard er alternativet "Graph Cleanup" aktivert, og alle irrelevante elementer vil bli fjernet fra grafen. Det ble forresten brukt i alle tidligere eksempler. Jeg ser for meg et naturlig spørsmål: hvordan kan vi sørge for at noe viktig ikke blir slettet? Jeg vil svare: for analytikere som liker å bygge grafer for hånd, kan automatisert rengjøring deaktiveres og antall trinn kan velges = 1. Deretter vil analytikeren kunne fullføre grafen fra elementene han trenger og fjerne elementer fra grafen som er irrelevant for oppgaven.

Allerede på grafen blir historien om endringer i whois, DNS, samt åpne porter og tjenester som kjører på dem, tilgjengelig for analytikeren.

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen

Finansiell phishing

Vi undersøkte aktivitetene til en APT-gruppe, som i flere år utførte phishing-angrep mot kunder fra forskjellige banker i forskjellige regioner. Et karakteristisk trekk ved denne gruppen var registreringen av domener som ligner veldig på navnene på ekte banker, og de fleste phishing-sidene hadde samme design, de eneste forskjellene er i navnene på bankene og deres logoer.

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen
I dette tilfellet hjalp automatisert grafanalyse oss mye. Ved å ta et av domenene deres - lloydsbnk-uk[.]com, bygde vi på noen få sekunder en graf med en dybde på 3 trinn, som identifiserte mer enn 250 ondsinnede domener som har blitt brukt av denne gruppen siden 2015 og som fortsatt brukes . Noen av disse domenene har allerede blitt kjøpt av banker, men historiske poster viser at de tidligere var registrert for angripere.

For klarhets skyld viser figuren en graf med en dybde på 2 trinn.

Det er bemerkelsesverdig at allerede i 2019 endret angriperne taktikken sin noe og begynte å registrere ikke bare domenene til banker for å være vert for nettfisking, men også domenene til ulike konsulentselskaper for å sende phishing-e-post. For eksempel domenene swift-department.com, saudconsultancy.com, vbgrigoryanpartners.com.

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen

Koboltgjeng

I desember 2018 sendte hackergruppen Cobalt, som spesialiserer seg på målrettede angrep på banker, en e-postkampanje på vegne av National Bank of Kazakhstan.

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen
Brevene inneholdt lenker til hXXps://nationalbank.bz/Doc/Prikaz.doc. Det nedlastede dokumentet inneholdt en makro som startet Powershell, som ville forsøke å laste og kjøre filen fra hXXp://wateroilclub.com/file/dwm.exe i %Temp%einmrmdmy.exe. Filen %Temp%einmrmdmy.exe aka dwm.exe er en CobInt stager konfigurert til å samhandle med serveren hXXp://admvmsopp.com/rilruietguadvtoefmuy.

Tenk deg at du ikke kan motta disse phishing-e-postene og utføre en fullstendig analyse av de skadelige filene. Grafen for det ondsinnede domenet nationalbank[.]bz viser umiddelbart forbindelser med andre ondsinnede domener, tilskriver det til en gruppe og viser hvilke filer som ble brukt i angrepet.

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen
La oss ta IP-adressen 46.173.219[.]152 fra denne grafen og bygge en graf fra den i én omgang og slå av rengjøring. Det er 40 domener knyttet til det, for eksempel bl0ckchain[.]ug
paypal.co.uk.qlg6[.]pw
kryptoelips[.]com

Etter domenenavnene å dømme, ser det ut til at de brukes i uredelige ordninger, men rensealgoritmen innså at de ikke var relatert til dette angrepet og la dem ikke på grafen, noe som i stor grad forenkler prosessen med analyse og attribusjon.

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen
Hvis du bygger om grafen ved å bruke nationalbank[.]bz, men deaktiverer grafrensealgoritmen, vil den inneholde mer enn 500 elementer, hvorav de fleste ikke har noe å gjøre med Cobalt-gruppen eller deres angrep. Et eksempel på hvordan en slik graf ser ut er gitt nedenfor:

Din vei ut, graf: hvordan vi ikke fant en god nettverksgraf og laget vår egen

Konklusjon

Etter flere år med finjustering, testing i reelle undersøkelser, trusselforskning og jakt på angripere, klarte vi ikke bare å lage et unikt verktøy, men også å endre holdningen til eksperter i selskapet til det. I utgangspunktet ønsker tekniske eksperter full kontroll over grafkonstruksjonsprosessen. Det var ekstremt vanskelig å overbevise dem om at automatisk grafkonstruksjon kunne gjøre dette bedre enn en person med mange års erfaring. Alt ble bestemt av tid og flere "manuelle" kontroller av resultatene av det grafen produserte. Nå stoler våre eksperter ikke bare på systemet, men bruker også resultatene det oppnår i sitt daglige arbeid. Denne teknologien fungerer inne i hvert av systemene våre og lar oss bedre identifisere trusler av enhver type. Grensesnittet for manuell grafanalyse er innebygd i alle Group-IB-produkter og utvider mulighetene for nettkriminalitet betraktelig. Dette bekreftes av analytikeranmeldelser fra våre kunder. Og vi fortsetter på sin side å berike grafen med data og jobbe med nye algoritmer ved å bruke kunstig intelligens for å lage den mest nøyaktige nettverksgrafen.

Kilde: www.habr.com

Legg til en kommentar