Browserudvidelser som spor: installation, rettigheder og ondsindede udvidelser

Forside › Analyse og fortolkning · Gennemgået oktober 2026 · Af John Nielsen

En browserudvidelse kører inde i brugerens session og kan, afhængigt af sine rettigheder, læse og ændre indholdet af alle sider, brugeren besøger, herunder webmail, CRM og administrationsportaler. Derfor er udvidelser både en angrebsvej og et spor. I en undersøgelse handler det om tre spørgsmål: Hvilke udvidelser var installeret i perioden, hvornår og hvordan kom de på, og hvad gav rettighederne adgang til? Artiklen beskriver, hvor svarene ligger i Chromium-browsere (Chrome og Edge) og Firefox, og hvordan de sikres, før nogen rydder op.

Hvor udvidelserne ligger

I Chromium-browsere ligger hver profil i sin egen mappe under brugerens AppData\Local, fx Google\Chrome\User Data\Default eller Microsoft\Edge\User Data\Default. Ekstra profiler hedder typisk Profile 1, Profile 2 og så videre. De relevante kilder er:

Mappen Extensions med en undermappe pr. udvidelses-id og derunder en mappe pr. version. Her ligger manifest.json, scripts og ressourcer.
Profilens indstillingsfiler (Preferences og Secure Preferences), som er JSON. De rummer bl.a. udvidelsens tilstand (aktiv eller deaktiveret), installationstidspunkt, installationskilde og de rettigheder, brugeren har godkendt.
Udvidelsens egne data i Local Extension Settings, IndexedDB og lignende LevelDB-lagre. Her kan konfiguration, cachede data og i værste fald indsamlede oplysninger ligge.

Firefox samler oplysningerne i profilmappen: extensions.json med metadata, installationsdato og kilde, og mappen extensions med selve pakkerne som .xpi-filer. Formaterne er beskrevet nærmere i Plist, LevelDB og andre app-formater.

Tidsstempler i Chromiums indstillingsfiler er typisk mikrosekunder siden 1601 (WebKit-tid), mens Firefox bruger millisekunder siden 1970. En forkert konvertering flytter et installationstidspunkt med århundreder eller timer, så omregningen skal dokumenteres. Se tidsstempelformater og konvertering.

Rettighederne er kernen

Manifestet erklærer, hvad udvidelsen må. To slags rettigheder er afgørende:

Værtsrettigheder, fx <all_urls> eller bestemte domæner · Læse og ændre indholdet af sider på de pågældende adresser
API-rettigheder som cookies, webRequest, tabs, history, scripting, nativeMessaging · Cookies, netværkstrafik, faneblade, historik, indsprøjtning af scripts og kommunikation med programmer på computeren

En udvidelse med værtsrettighed til alle sider og adgang til cookies kan i princippet læse sessionscookies til webmail og cloudtjenester. Det betyder ikke, at den har gjort det, men det afgrænser, hvilke data der var eksponeret, og hvilke konti der bør undersøges for misbrug af sessioner. Rettighederne kan ændre sig mellem versioner, så rettighederne skal læses for den version, der var installeret i den relevante periode, og ikke kun for den nuværende.

Hvordan kom udvidelsen på?

Installationskilden skelner typisk mellem udvidelser fra den officielle butik, udvidelser tvunget ind via politik, udvidelser installeret af et andet program og udpakkede udviklerudvidelser indlæst fra en lokal mappe. De sidste to er de interessante i en kompromitteringssag, fordi de ikke går gennem butikkens kontrol.

Politikker ligger i registreringsdatabasen under HKLM\SOFTWARE\Policies\Google\Chrome og HKLM\SOFTWARE\Policies\Microsoft\Edge, fx ExtensionInstallForcelist, ExtensionInstallAllowlist og ExtensionInstallBlocklist. En tvungen udvidelse, som IT ikke kender, er et stærkt fund: Den kræver administratorrettigheder eller adgang til den centrale styring, og den peger dermed på en anden og mere alvorlig adgangsvej end en bruger, der har klikket “Tilføj”. Politikken skal holdes op mod gruppepolitik, Intune eller browserens cloudstyring, så det kan afgøres, hvor den kom fra.

Synkronisering forvirrer attributionen

Er browserprofilen logget ind med en konto, synkroniseres udvidelser mellem brugerens enheder. En udvidelse kan derfor være installeret på en privat computer og være dukket op på arbejdscomputeren via synkroniseringen. Installationstidspunktet på arbejdscomputeren er så tidspunktet for synkroniseringen, ikke for brugerens valg. Det samme problem gælder historik og bogmærker; se synkronisering mellem enheder for den generelle problemstilling.

Sådan sikres sporene

Sikr før oprydning. Fjernes udvidelsen fra browseren eller via politik, forsvinder mappen og ofte også dens lokale data. Brug flygtighedsrækkefølgen: kører browseren stadig, kan hukommelsen indeholde mere end disken, se flygtighedsorden.
Kopiér hele profilmappen for alle browsere og profiler på maskinen, inklusive indstillingsfiler, udvidelsesmapper og udvidelsesdata, og hash kopien.
Sikr registreringsdatabasen, især SOFTWARE-hiven med politikkerne og brugerens NTUSER.DAT.
Hent den centrale styring: browserstyringens rapporter over installerede udvidelser, ændringslog i politikkonsollen og eventuelle EDR-data om filer skrevet i profilmappen.
Bevar pakken. Selve udvidelsesfilerne gør det muligt at fastslå, hvad koden gjorde, også hvis butikken senere fjerner udvidelsen.

Opdagelse på tværs af maskiner

For SOC’en er spørgsmålet ofte, om andre er ramt. Udvidelses-id’et er stabilt på tværs af maskiner, så det kan søges i inventar fra EDR, browserstyring eller et indsamlingsscript, der læser profilmapperne. Sammenlign med en godkendt liste. Udvidelser, der er fjernet fra butikken, eller som har skiftet ejer og pludselig har fået nye rettigheder i en opdatering, er klassiske røde flag.

Typiske spørgsmål i en sag

Udvidelser dukker op i tre slags sager. Ved en overtaget mailkonto uden tydelig phishing kan en udvidelse med adgang til cookies forklare, hvordan sessionen blev overtaget, og tidspunktet for installationen kan holdes op mod de første fremmede logins i loginloggen. Ved mistanke om dataudtræk i forbindelse med en fratræden kan en udvidelse til skærmoptagelse, filoverførsel eller automatisk kopiering af sider være relevant. Og ved en tvist om ansvar efter et angreb kan det betyde noget, om udvidelsen kom på via politik, som IT styrede, eller via brugerens eget valg. I alle tre tilfælde er det tidslinjen, der bærer: installation, versionsskift, rettighedsændringer og de handlinger i andre logs, der følger efter.

Fejlkilder

Forudinstallerede komponenter: Browsere har indbyggede udvidelser og komponenter, som ligner tredjepartsudvidelser i mappestrukturen.
Opdateringer: En ny versionsmappe betyder normalt en automatisk opdatering, ikke en ny installation.
Deaktiveret er ikke fjernet: En deaktiveret udvidelse ligger stadig på disken, men har ikke kørt i den periode.
Flere profiler: Profilen Default er ikke nødvendigvis den, brugeren arbejdede i.
Netværkstrafik: Hvad en udvidelse sendte, ses ikke i browseren selv. Det kræver proxy-, DNS- eller firewalllogs, se proxy- og webfilterlogs.

Hvad sporene kan og ikke kan vise

Sporene kan vise, at en bestemt udvidelse i en bestemt version var installeret og aktiv i en profil fra et bestemt tidspunkt, hvilke rettigheder den havde, og om den kom via butik, politik eller lokal indlæsning. De kan ikke alene vise, hvilke data udvidelsen faktisk læste eller sendte, eller hvem der klikkede på installationen. Det kræver kodeanalyse, netværksdata og koblingen til, hvem der brugte profilen. Sammenhængen med cookies og sessioner er beskrevet i browsercache, cookies og gemte sessioner.

Dokumentation

Angiv browser og version, profilsti, udvidelses-id, navn, version, installationskilde, installationstidspunkt med konvertering og tidszone, rettigheder for den relevante version samt hashværdier for pakke og profilkopi. Beskriv, hvordan synkronisering er vurderet, og hvilke centrale kilder der er brugt til at bekræfte eller afkræfte installationsvejen.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Analyse og fortolkning

Læs også: AI-notetagere og mødetransskriptioner · Privat browsing og inkognito: hvilke spor findes alligevel

→ Digital forensics-undersøgelse · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik