Forsyningskjedeintrengninger har blitt den typiske angrepsmetoden det siste tiåret: NotPetya via en ukrainsk skatteprogramvareoppdatering, SolarWinds Orion, Kaseya VSA, 3CX, XZ Utils. Hver gang lærer forsvarerne den samme leksjonen på den harde måten. En signert binærfil fra en pålitelig leverandør er ingen garanti, det er kun et utgangspunkt. Det som følger er en anonymisert beskrivelse av en reell hendelse der vår administrerte XDR fanget en leverandørlevert oppdatering som kjørte angriperkontrollert kode i løpet av minutter, begrenset skadeomfanget før noen dataeksfiltrering fant sted, og lot en nordisk logistikkoperatør gjenoppta driften samme morgen.

Miljøet

Kunden kjører en typisk mellomstor bedriftsstack: Windows 11-endepunkter styrt via Intune, hybrid Active Directory koblet til Entra ID, to Azure-regioner, et OT-segment i lageret, samt en flåte med robuste Android-enheter for sjåførene. De sender all sikkerhetstelemetri inn i vår administrerte XDR: endpoint EDR på alle verter, NDR-sensorer på tre transittpunkter, skyrevisjon fra Azure og Microsoft 365, identitetstelemetri fra Entra ID, i tillegg til DNS- og brannmurlogger. Omtrent 4,2 millioner hendelser per dag kommer inn i analyseplattformen. Et 24/7 norsk SOC ligger på toppen.

Hva plattformen så, minutt for minutt

Angriperen kom inn gjennom en legitim leverandør av byggautomatisering. Oppdateringsagenten fra denne leverandøren var installert på omtrent 60 av kundens endepunkter. Inntrengningen utviklet seg som følger.

T+00:00: innhenting

02:14:07 UTC. Leverandørens oppdateringstjeneste, som kjører som SYSTEM på en filserver i varehuset, kontakter sitt vanlige oppdateringsendepunkt. Dette skjer hver fjerde time og har skjedd i to år. HTTPS-forespørselen er umulig å skille fra alle tidligere forespørsler.

T+00:08: første avvik

02:14:15 UTC. I stedet for å hente en enkelt signert nyttelast, utfører oppdateringstjenesten en ny DNS-oppslag. Denne gangen for et domene som ble registrert bare 41 timer tidligere. DNS-sensoren flagger oppslaget mot vår feed for nylig observerte domener. Alene er én slik DNS-forespørsel per prosess knapt nok til å lage støy.

T+00:14: korrelasjon utløses

02:14:21 UTC. Endepunktagenten observerer at leverandørens oppdateringstjeneste starter powershell.exe med base64-kodede argumenter og parametrene -NoProfile -EncodedCommand. XDR-motoren korrelerer tre svake signaler til én sterk hendelse:

• Ukjent underprosess-avstamning (baselinen sier at denne tjenesten aldri starter PowerShell)
• DNS-oppslag til et domene yngre enn 72 timer
• Script block logging viser et staged downloader-mønster med in-memory reflection

Den samlede scoren overskrider eskaleringsterskelen. Hendelse #IR-2025-0128 opprettes automatisk og tildeles vakthavende analytiker.

T+00:19: SOC varslet

02:14:26 UTC. PulseGuard ruter hendelsen til vår vakthavende og eskaleringsteam. Hendelsespakken inneholder prosess-treet, dekodet PowerShell, DNS-hendelsen, destinasjons-IP'en (som matcher et ASN vi tidligere har flagget for commodity-loader-infrastruktur), samt en ferdigutarbeidet containment-playbook.

T+00:23: begrensning starter

02:14:30 UTC. Analytikeren bekrefter at detonasjonen er aktiv. Automatiserte playbooks kjører parallelt: det berørte endepunktet nettverksisoleres via EDR-agenten; brannmuren legger inn den ondsinnede FQDN'en og IP'en som blokker; DNS-resolveren null-ruter domenet; oppdateringsagentens tjenestekonto tvinges til å reautentisere; og disk og minne fra den kompromitterte maskinen tas ut for rettsmedisinsk analyse.

T+03:47: fult skadeomfang kartlagt

02:17:54 UTC. Ved å kryssjekke signaturen til leverandørens oppdateringstjeneste på alle 60 verter der den var installert, viser det seg at seks av dem allerede hadde kjørt second-stage downloaderen, men ingen hadde fullført tredje trinn. Alle seks er isolert. Kundens IT-ledelse er nå aktivt involvert i hendelseshåndteringen.

T+14:12: angriperen ute

02:28:19 UTC. Ingen sesjoner er lenger etablert mot angriperens infrastruktur. Ingen legitimasjoner ble klargjort. Ingen data forlot nettverket. Rettsmedisinsk analyse bekrefter at angriperen hadde fotfeste i omtrent 14 minutter på seks endepunkter og aldri kom lenger enn rekognoseringsfasen.

Hva angrepet egentlig var

En oppstrømsundersøkelse (koordinert med leverandøren og CERT-EU) avdekket at leverandørens build pipeline var kompromittert omtrent ni dager tidligere. En angriper med tilgang til en GitLab CI-runner hadde injisert en liten loader i leverandørens oppdateringsnyttelast. Loaderen kjørte kun når to betingelser var oppfylt: målet var domenetilknyttet, og vertsnavnet startet ikke med en streng som ekskluderte leverandørens eget QA-miljø. Alle sendte oppdateringer var korrekt signert med leverandørens kodesigneringssertifikat fordi injeksjonen skjedde før signeringssteget. Dette er akkurat derfor ren signaturbasert tillit svikter: binærfilen var gyldig, sertifikatet var gyldig, utstederen var gyldig, og oppdateringskanalen var den ekte.

Kartlegging til MITRE ATT&CK

• Initial Access: Forsyningskjede-kompromiss: Kompromittering av programvares forsyningskjede (T1195.002)
• Execution: Kommando- og skripttolker: PowerShell (T1059.001)
• Defense Evasion: Signert binærfil-proxy-utførelse (T1218) og Obfuskering av filer eller informasjon: Kommandoobfuskering (T1027.010)
• Command and Control: Applikasjonslagsprotokoll: DNS (T1071.004) samt Dynamisk oppløsning: Fast Flux DNS (T1568.001)
• Discovery: Systeminformasjonsoppdagelse (T1082), Domene-tillitsoppdagelse (T1482)
• Credential Access: Klargjort men ikke utført (T1003-kandidatnyttelast funnet i minnet)

Deteksjonslogikken forklart med enkle ord

Det fantes ingen malware-hash å matche mot. Det fantes ingen IP-adresse på noen blokkeringsliste. Sertifikatet var gyldig. Domenet var teknisk sett nytt, men sto ikke på noen feed på det tidspunktet. Den eneste grunnen til at denne deteksjonen fungerte, var at vi korrelerte flere ting som en menneskelig analytiker aldri ville ha rukket å se på enkeltvis:

1. En pålitelig, lenge kjørende tjeneste som startet et skriptverktøy den aldri hadde startet før – basert på en flåteomfattende atferdsbaseline.
2. En DNS-forespørsel til et nylig observert domene fra en SYSTEM-nivå prosess på en uvanlig tid.
3. Utgående trafikk til et ASN som var flagget av vår threat-intel-plattform, selv om den spesifikke IP-en var ukjent.
4. En PowerShell-kjøring der script block-en matchet en familie av reflective loaders, skåret av maskinlæring i stedet for hash.

Ett av disse signalene alene er bare støy. XDR-plattformens oppgave er å oppdage at alle fire signalene utløste på samme prosess-tre innen 14 sekunder og behandle det som en hendelse, ikke bare en loggpost.

Hva som skjedde i løpet av de neste 72 timene

I kundens miljø roterte vi leverandørens tjenestekonto-legitimasjon, gjenutstedte alle hemmeligheter lagret på de seks berørte vertene, nullstilte deres lokale maskinkontoer, og la til en flåteomfattende EDR-regel som blokkerer leverandørens oppdateringstjeneste fra å starte noen form for skriptverktøy de neste 30 dagene mens leverandøren gjenoppbygger pipelinen sin.

Oppstrøms delte vi vår deteksjon og det rettsmedisinske materialet med leverandøren og med to andre managed security-leverandører som kjører samme telemetri. Innen 24 timer ble den kompromitterte runneren tatt ut av drift, signeringsnøkkelen rotert, og en ren oppdatering ble levert. Vår kunde var blant de første som mottok varsel og en ren build fordi vi satt på den tidligste rettsmedisinske dokumentasjonen.

Herding som overlever neste angrep

Hvert forsyningskjedeangrep avslører de samme strukturelle svakhetene. Anbefalingene som kom ut av denne hendelsen, og som vi nå har innlemmet i vår standard herdings-playbook:

• Anta at signert ikke betyr trygt. Atferdsbaselining på alle langkjørende privilegerte tjenester, med varsling ved enhver avvik i underprosesser, er nå et minimumskrav.
• Utgående trafikk er et produkt, ikke en funksjon. Eksplisitte DNS-tillatelister for automatiseringskontoer, med varsling på nylig observerte domener, fanger loadere før nyttelasten lander.
• Identitet er fortsatt den nye perimeteren. Leverandørers tjenestekontoer skal behandles som førsteklasses identiteter med betinget tilgang, begrenset token-levetid og risikovurdering av sesjoner.
• Script block-logging overalt. PowerShell (og cmd.exe, wscript og alle andre automatiserings-skall) bør sende full kommando-tekst inn i telemetri-plattformen. Redigering på analytikernivå er billig; retrospektiv rettsmedisinsk analyse uten logger er det ikke.
• Test responsen, ikke bare forsvaret. Den fire minutter lange begrensningstiden i denne hendelsen var et resultat av bordøvelser utført på kundens faktiske topologi. Playbooks som bare finnes i PDF-er, er ikke playbooks.

Hvorfor denne typen deteksjon krever hele plattformen

Denne deteksjonen var bare mulig fordi endepunkttelemetri, DNS-logger, identitetshendelser og threat-intel-kontekst alle havnet i samme spørringsplan og ble evaluert av den samme korrelasjonsmotoren. Et siloet SIEM ville ha fanget opp hvert enkelt signal, men gått glipp av sammenhengen. En EDR uten nettverkskontekst ville ha sett en PowerShell-start og vurdert den som ufarlig fordi forelderprosessen var en signert tjeneste. En NDR uten endepunktkontekst ville ha sett en DNS-forespørsel til et nytt domene og trukket på skuldrene.

Verdien av XDR som modell, og grunnen til at vi leverer det som en administrert tjeneste for kundene våre, er at korrelasjonen ikke lenger er analytikerens jobb. Korrelasjonen er plattformen. Analytikerens jobb er å vurdere hva korrelasjonen betyr og hvordan man skal respondere. Denne oppdelingen er akkurat det som gir fire minutters begrensning.

Hvis du driver virksomhet i Norge og har lest så langt

Vårt SOC drives fra Norge, rapporterer på norsk, etterlever norske datalokaliseringskrav og lagrer all kundetelemetri på infrastruktur vi selv drifter og kontrollerer. Hvis du ønsker den samme deteksjonsplattformen i ditt miljø, ta kontakt, så fikser vi det for deg.