Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen
Indgangsvejen er det første sted, angriberen fik adgang til miljøet: en VPN-konto, en åben RDP-port, en sårbar server mod internettet, en phishingmail eller en leverandørs fjernadgang. Konklusionen om indgangsvejen bærer ofte en hel tvist, fordi den afgør, om et sikkerhedskrav i forsikringspolicen var opfyldt, og om IT-leverandøren havde ansvaret for det svage punkt. Den skal derfor bygges op af konkrete spor, med en angivelse af, hvor sikker den er, og hvilke alternative forklaringer der er afprøvet.
Haster det? Indgangsvejen ligger ofte uger tilbage, og VPN-, firewall- og loginlogs fra den periode kan rotere ud, mens genopretningen står på. Se akut forensisk sikring; hastesager koster ekstra.
Artiklen handler om et angreb på virksomhedens netværk. Den samlede undersøgelse efter angrebet er beskrevet under undersøgelse efter hackerangreb, og indgangsvejen til en hacket WordPress-side i Indgangsvejen i WordPress.
Fra den første kendte hændelse og baglæns
Analysen starter typisk ved den tidligste ondsindede aktivitet, man kender, fx et værktøj kørt på en server eller et login med en konto, der ikke burde være brugt. Derfra arbejdes baglæns: Hvordan kom angriberen til den maskine? Med hvilken konto? Fra hvilken anden maskine eller hvilken ekstern adresse? Hvert skridt baglæns kræver en kilde, og kæden stopper, hvor kilderne stopper.
Det er afgørende at skelne mellem det første kendte spor og det første spor. Har loggene kun 30 dages historik, og er den første kendte hændelse 29 dage gammel, er det sandsynligt, at forløbet begyndte før, og at den egentlige indgang ligger uden for den periode, der kan undersøges. Hvornår kompromitteringen begyndte, er behandlet i Dwell time.
De typiske indgange og deres spor
VPN og fjernadgang med gyldige legitimationsoplysninger
Spor: VPN-loginlogs med brugernavn, kildeadresse, klient og tidspunkt, eventuelt fejlede forsøg forud, MFA-status og den interne adresse, sessionen fik tildelt. Den tildelte adresse kan derefter følges i interne logs. Se VPN-logs. Mange fejlede forsøg fra mange adresser før et vellykket login peger på gætning af adgangskoder, se Password spray og brute force. Et vellykket login uden forudgående fejl peger snarere på, at adgangskoden var kendt på forhånd, fx fra et tidligere læk eller en phishingmail.
RDP eksponeret mod internettet
Spor: firewallregler og NAT-konfiguration, der viser eksponeringen, logonhændelser af type 10 i Windows-sikkerhedsloggen, RemoteConnectionManager– og LocalSessionManager-logs og eventuelt bitmap-cache på klienten. Se RDP-spor. Eksponeringen alene beviser ikke, at den blev brugt. Det kræver logonhændelser fra en ekstern adresse.
Sårbarhed i et system mod internettet
Spor: systemets version og patchniveau på hændelsestidspunktet, webserver- eller applikationslogs med forespørgsler, der matcher kendte udnyttelsesmønstre, nye filer i webmapper og processer startet af tjenestens konto. Patchniveauet skal dokumenteres for tidspunktet, ikke for i dag. Konfigurationsstyring, opdateringslogs og leverandørens release-noter kan bruges til at fastslå det.
Phishing og ondsindede vedhæftninger
Spor: den modtagne mail i postkassen og i message trace, klikregistreringer, browserhistorik, filer i downloadmappen og procesforløbet på klienten. Se Ondsindede vedhæftninger. En phishingmail i indbakken beviser ikke, at den blev brugt. Kæden skal fra mailen til en konkret handling på en konkret maskine.
Leverandørens adgang
Spor: RMM-logs, leverandørens egne konti, fjernsupportsessioner og identitetsudbyderens logs. Her ligger en del af data typisk hos leverandøren, og det skal fremgå, om de er stillet til rådighed i fuldt omfang.
Evidensniveauer
Konklusionen bør angives med en grad af sikkerhed, der er knyttet til konkrete kriterier. En enkel skala kunne være:
- Påvist: en sammenhængende kæde af spor fra den eksterne kilde til den første kendte ondsindede handling, uden huller af betydning.
- Sandsynlig: spor, der peger på indgangen, men med et hul i kæden, fx manglende logs i et kort tidsrum.
- Mulig: indgangen var teknisk til stede og er forenelig med forløbet, men der er ingen direkte spor af, at den blev brugt.
- Udelukket: spor viser, at indgangen ikke blev brugt i den relevante periode.
Brug de samme ord konsekvent i hele rapporten, og forklar dem. En gennemgang af konklusionsgrader findes i Konklusionsgrader i forensik.
Alternative forklaringer
En stærk konklusion viser ikke kun, at en indgang er forenelig med sporene, men også, at de andre ikke er. For hver realistisk indgang bør rapporten beskrive, hvad der er undersøgt, og hvad det viste:
- Hvis konklusionen er VPN med stjålet adgangskode: Er det undersøgt, om samme konto loggede ind andre steder, fx i Microsoft 365, med samme kildeadresse? Er der tegn på phishing mod brugeren i perioden?
- Hvis konklusionen er en sårbarhed: Er det undersøgt, om der også var gyldige logins via fjernadgang i samme tidsrum?
- Hvis konklusionen er RDP: Var der andre eksponerede tjenester på samme tidspunkt?
Det er også relevant at nævne, når flere indgange kan have været brugt. Angribere bruger nogle gange én vej til den første adgang og en anden til at vende tilbage.
Når indgangsvejen ikke kan fastlægges
Det sker ofte, at kilderne simpelthen ikke rækker. Loggene er roteret, den første kompromitterede maskine er geninstalleret, eller den relevante log blev aldrig slået til. Så er det korrekte svar, at indgangsvejen ikke kan fastlægges, eventuelt suppleret med, hvilke indgange der kan udelukkes, og hvilke der fortsat er mulige.
Det er et fuldt legitimt resultat og langt bedre end en konklusion, der ikke kan bære et kritisk spørgsmål. Et forsikringsselskab eller en skønsmand vil typisk spørge direkte til, hvilke kilder konklusionen bygger på. Kan svaret ikke gives, falder konklusionen, og troværdigheden af resten af rapporten følger med.
Beskriv i så fald, hvilke data der ville have været nødvendige, og hvorfor de ikke findes. Det kan i sig selv være relevant for spørgsmålet om ansvar, fx hvis en aftalt logning ikke var sat op.
Spor uden for eget miljø
Nogle af de vigtigste spor ligger hos andre: VPN-leverandørens cloudportal, firewallproducentens administrationstjeneste, leverandørens RMM-platform eller mailudbyderens logs. Bed om dem tidligt, og bed om dem i et format med alle felter, ikke som skærmbilleder. Notér, hvornår der er bedt om dem, og hvad der er modtaget. Data, som en part i tvisten selv har udtrukket, bør så vidt muligt kunne kontrolleres mod en uafhængig kilde.
Faldgruber
- At slutte fra eksponering til brug. En åben port eller en upatchet server er en risiko, ikke et bevis for indgangen.
- At stoppe ved den første plausible forklaring. Bekræftelsesbias er en reel risiko, især hvis rapporten skrives af den part, der har en interesse i svaret.
- Kildeadresser som identitet. En ekstern IP-adresse siger sjældent, hvem der stod bag. Den kan tilhøre en VPN-tjeneste, en lejet server, en anden kompromitteret virksomhed eller et mobilnet med delte adresser.
- Tidszoner på tværs af enheder. VPN-koncentratoren, firewallen og Windows kan logge i hver sin tidszone.
- Huller, der tolkes som stilhed. Manglende logs betyder ikke, at intet skete.
Dokumentation
Rapporten bør vise kæden fra indgang til første kendte ondsindede handling som en tidslinje, hvor hver post har kilde, tidspunkt med tidszone og en kort beskrivelse af, hvad posten viser. Ved siden af kæden en tabel over de undersøgte alternative indgange og resultatet for hver. Angiv tydeligt de perioder og systemer, hvor data manglede.
Hvordan indgangsvejen bruges i en tvist mellem virksomhed og IT-leverandør, og hvad den juridisk kan og ikke kan bære, er beskrevet fra advokatens side i Cyberangreb: tvisten med IT-leverandøren.
Kilder og versioner
- Microsoft Learn: Event 4624, an account was successfully logged on (logontyper)
- NIST SP 800-61 Rev. 3: Incident Response Recommendations
- MITRE ATT&CK: Initial Access (TA0001)
Senest gennemgået: oktober 2026.
Næste skridt
- Cyberforsikringen: de tekniske leverancer, forsikringsselskabet beder om
- Forsikringstvist: dokumentation af sikkerhedsniveauet før hændelsen
- Persondatabrud på 72 timer: de tekniske fakta, der skal være fastlagt
Del af: Undersøgelse efter et hackerangreb
Læs også: Ransomware: bevissikring parallelt med genopretning · Dataudtræk før kryptering: spor efter eksfiltration
→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
