Gå til indhold
atlas

Trusselsjagt (threat hunting)

Også kendt som: threat hunting

Målrettet søgning efter angribere, der måske allerede er inde i netværket, uden at vente på, at en alarm går i gang.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

En gentaget, menneskeledet søgning gennem logs og data fra endpoints, der tager udgangspunkt i et gæt om, hvordan en angriber kunne handle, ofte hentet fra MITRE ATT&CK, for at finde aktivitet, som detektionsreglerne overså, og som ender med at afvise gættet eller åbne en hændelse.

Forklaret enkelt

Som en butiksdetektiv, der går rundt i butikken og kigger efter kendte kneb, i stedet for kun at vente på, at alarmen ved døren bipper.

I praksis

Efter at have læst i en rapport fra CFCS, at en kriminel gruppe stjæler adgangskoder med et bestemt administratorværktøj, gennemsøger en trusselsjæger i en pensionskasse tre måneders data fra endpoints, finder værktøjet på én server og sender sagen videre til hændelseshåndteringen.

Hvorfor det betyder noget

Dygtige angribere undgår at udløse alarmer og kan holde sig skjult i månedsvis; trusselsjagt forkorter den tid, og hver jagt, der lykkes, kan blive til en ny detektionsregel.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Tjek, at data findes, før I planlægger jagter - procesoprettelse med kommandolinjer, EDR-telemetri, autentificeringslogs og netværksmetadata - og at de gemmes længe nok og har synkroniserede tidsstempler.
  2. Hav en liste over hypoteser hentet fra threat intelligence og de MITRE ATT&CK-teknikker, der er mest relevante for jer, hver så konkret, at den kan afprøves, fx dump af legitimationsoplysninger fra LSASS på servere med et omdøbt administrationsværktøj.
  3. Notér for hver jagt hypotesen, datakilderne, tidsperioden, og hvordan et fund vil se ud, før I begynder at søge.
  4. Gennemsøg data med teknikker som stacking af sjældne par af forælder- og børneprocesser eller autoruns på tværs af maskinparken, søgning efter regelmæssig beaconing i netværkstrafikken og pivotering fra et mistænkeligt fund til relaterede maskiner og konti.
  5. Finder I reel angriberaktivitet, så stop jagten, og send sagen videre til hændelseshåndteringen med det samme.
  6. Dokumentér hver jagt, også dem uden fund, så I kan vise, hvad der blev afprøvet mod hvilke data i hvilken periode.
  7. Omsæt det, hver jagt lærer jer, til varige forbedringer - nye eller bedre detektionsregler, lukkede huller i logning eller opbevaring og et bedre billede af normal adfærd.
  8. Gennemfør jagter efter en fast plan, fx hver måned, og mål programmet på de detektioner og forbedringer, det giver, frem for antallet af fundne hændelser.

Typiske faldgruber

  • At jage uden telemetri fra endpoints eller uden logs, der gemmes længe nok, så det mest bliver gætteri.
  • At kalde en søgning efter kendte kompromitteringsindikatorer for en jagt og aldrig afprøve den adfærd, som indikatorerne overser.
  • At kassere jagter, der ikke fandt noget, i stedet for at dokumentere dem og gøre dem til detektioner.

Gode vejledninger

Teknisk uddybning

Trusselsjagt bygger på en antagelse om, at et brud allerede er sket: forebyggende kontroller og detektionsregler vil overse nogle indbrud, så analytikerne søger proaktivt efter tegn på kompromittering, der ikke har udløst en alarm. Den klassiske procesmodel er det hunting loop, som Sqrrl gjorde udbredt i midten af 2010'erne: formulér en hypotese, undersøg med værktøjer og teknikker, afdæk nye mønstre og TTP'er, og informér og berig analyserne. De samme forfattere foreslog Hunting Maturity Model, fra HMM0 (bygger kun på automatiske alarmer) til HMM4 (de fleste vellykkede jagter automatiseres til detektioner). Splunks PEAK-rammeværk (2023) formaliserer tre typer jagt: hypotesedrevne jagter, baseline- eller udforskende jagter, der karakteriserer normal adfærd for at finde afvigelser, og modelassisterede jagter, der bruger maskinlæring.

Hypoteser er specifikke og kan afprøves, og de udspringer som regel af threat intelligence eller af en ATT&CK-teknik, der er relevant for organisationen, fx: "en angriber med fodfæste dumper legitimationsoplysninger fra LSASS-hukommelsen (T1003.001) på servere med et omdøbt eller signeret administrationsværktøj". Trusselsjægeren identificerer derefter de nødvendige data, fx procesoprettelse med kommandolinjer, procesadgangshændelser (Sysmon-hændelses-id 10 for adgang til lsass.exe), EDR-telemetri, autentificeringslogs eller netværksmetadata fra Zeek, og kontrollerer, om disse data faktisk indsamles og opbevares længe nok. Hyppige analyseteknikker er stacking eller least frequency of occurrence-analyse (sjældne par af forælder- og børneprocesser, sjældne autoruns på tværs af maskinparken), tidsserieanalyse for at finde beaconing og pivotering fra et mistænkeligt artefakt til relaterede maskiner og identiteter.

En jagt har tre mulige udfald, og de er alle nyttige. Et bekræftet fund bliver en hændelse og overdrages til hændelseshåndteringen. Et negativt resultat, der er veldokumenteret, viser, at hypotesen er afprøvet mod definerede data over en defineret periode. Og næsten hver jagt giver biprodukter: nye eller forbedrede detektionsregler, fundne huller i logning eller opbevaring og en bedre baseline for normal adfærd. Modne teams følger disse resultater, frem for antallet af fundne hændelser, som målet for programmets værdi.

Trusselsjagt adskiller sig fra triage af alarmer, som er reaktiv og tager udgangspunkt i en alarm, og fra indikatorsøgninger, der gennemsøger logs efter kendte IoC'er; en IoC-søgning kan indgå i en jagt, men er ikke jagt i den hypotesedrevne forstand. Den adskiller sig også fra penetrationstest og red teaming, der simulerer angribere i stedet for at lede efter rigtige. Effektiviteten afhænger af data: jagt uden telemetri fra endpoints, tilstrækkelig opbevaring og synkroniserede tidsstempler er for det meste gætteri. Praksissen er vigtig, fordi dwell time, tiden fra indbrud til opdagelse, i branchens rapporter stadig typisk måles i dage til uger, og målrettede angribere bevidst holder sig under alarmtærsklerne.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Log
  2. →CIA-triaden
  3. →Detektionsregel
  4. →Sikkerhedshændelse
  5. →Kompromitteringsindikator (IoC)
  6. →Trusselsjagt (threat hunting)

Relationer

Forveksl ikke med
Triage af alarmer

Kilder og videre læsning

Opslagsværker

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.