Intern penetrationstestning av nätverk: handbok för 2026
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Intern penetrationstestning av nätverk: handbok för 2026
Intern penetrationstestning simulerar vad en angripare kan åstadkomma efter att det yttre försvaret redan har fallit — eller när hotet kommer inifrån. Till skillnad från extern testning och automatiserade skanningar avslöjar interna tester laterala rörelsemönster, felkonfigurerade Active Directory-behörigheter och okrypterad intern trafik som utgör den faktiska attackytan i de flesta organisationer. Med NIS2-direktivets krav på dokumenterade säkerhetstester och ISO/IEC 27001:s kontrollmål är intern pentestning inte längre valfritt — det är en operativ nödvändighet.
Viktiga slutsatser
- Intern penetrationstestning avslöjar sårbarheter som yttre skydd aldrig fångar — laterala rörelser, felkonfigurerade AD-behörigheter och okrypterad intern trafik
- NIS2-direktivet och ISO/IEC 27001 kräver dokumenterade, återkommande säkerhetstester — inte bara automatiserade skanningar
- Skillnaden mellan sårbarhetsskanning och penetrationstest avgör om ni faktiskt förstår er riskexponering eller bara bockar av en checklista
- En strukturerad testcykel (rekognosering → exploatering → lateral rörelse → rapportering) ger handlingsbara åtgärder istället för generiska larmlistor
Vad intern penetrationstestning faktiskt innebär
Begreppet missförstås ofta. Många organisationer tror att ett internt penetrationstest innebär att köra Nessus eller Qualys mot interna IP-adresser och presentera resultatet i en PDF. Det är en sårbarhetsskanning — inte ett penetrationstest.
Ett internt penetrationstest utgår från att en angripare redan har fotfäste i nätverket. Det kan vara en komprometterad arbetsstation, en insiders behörigheter eller en nätverksuttag i ett konferensrum. Testaren agerar sedan som en verklig hotaktör: kartlägger nätverket, identifierar svaga punkter, eskalerar privilegier och rör sig lateralt mot de mest kritiska systemen.
Från Opsios SOC i Karlstad ser vi dagligen vad den här typen av testning avslöjar i produktionsmiljöer: service-konton med domänadmin-behörigheter som ingen har granskat på tre år, VLAN-segmentering som existerar på pappret men inte i praktiken, och NTLM-autentisering som fortfarande är aktiverad trots att organisationen "gått över till Kerberos".
Sårbarhetsskanning kontra penetrationstest
| Dimension | Sårbarhetsskanning | Intern penetrationstestning |
|---|---|---|
| Metod | Automatiserad; jämför konfigurationer mot kända CVE:er | Manuell + automatiserad; exploaterar sårbarheter aktivt |
| Djup | Bred men ytlig — identifierar potentiella svagheter | Djup — bevisar faktisk exploaterbarhet och affärspåverkan |
| Resultat | Lista med sårbarheter och CVSS-poäng | Attacknarrativ med bevisad lateral rörelse och dataexfiltrering |
| Regulatorisk acceptans | Otillräckligt som enda åtgärd för NIS2/ISO 27001 | Uppfyller krav på dokumenterad säkerhetstestning |
| Frekvens | Kontinuerligt/veckovis | Minst årligen; kvartalsvis vid hög risk |
| Kostnad | Låg (verktygsbaserad) | Medel–hög (kräver kvalificerade testare) |
Poängen är inte att sårbarhetsskanningar saknar värde. De är en hygienfaktor. Men att presentera en skanningsrapport för en NIS2-revision och hävda att ni har "testat er säkerhet" är ungefär som att kontrollera att dörrlåset finns utan att pröva om det faktiskt håller.
Vill ni ha expertstöd med intern penetrationstestning av nätverk: handbok för 2026?
Våra molnarkitekter hjälper er med intern penetrationstestning av nätverk: handbok för 2026 — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.
Varför intern testning är kritisk — inte bara ett compliance-krav
Extern penetrationstestning fångar vad som är synligt från internet: exponerade portar, felkonfigurerade brandväggar, sårbara webbtjänster. Men de flesta avancerade angrepp slutar inte vid perimetern — de börjar där.
Enligt MITRE ATT&CK-ramverket sker majoriteten av skadlig aktivitet i fas T1021 (Remote Services), T1078 (Valid Accounts) och T1053 (Scheduled Task/Job) — tekniker som uteslutande opererar innanför nätverkets yttergräns. Det innebär att en organisation som enbart testar externt saknar insyn i den största delen av sin faktiska attackyta.
Vad Opsios SOC faktiskt ser i produktion
Tre mönster återkommer i nästan varje intern testning vi stödjer:
1. Active Directory som akilleshäl. Microsofts identitetsinfrastruktur är central i de flesta svenska organisationer, och den är nästan alltid mer exponerad internt än vad IT-avdelningen tror. Kerberoasting, AS-REP roasting och Golden Ticket-attacker fungerar fortfarande — inte för att teknikerna är nya, utan för att grundkonfigurationen sällan härdas tillräckligt.
2. Nätverkssegmentering som existerar på pappret. Vi ser regelbundet miljöer där VLAN:en är konfigurerade men inter-VLAN-routing tillåter fri trafik. En testare som komprometterar en arbetsstation i ett kontorssegment kan nå produktionsdatabaser utan att passera en enda brandväggsregel.
3. Interna tjänster utan kryptering. LDAP utan TLS, SMBv1 fortfarande aktiverat, intern webbtrafik över HTTP. I en intern testning fångas dessa upp genom MITM-attacker (man-in-the-middle) som visar att känslig data — inklusive autentiseringsuppgifter — passerar nätverket i klartext.
Testprocessen steg för steg
En strukturerad intern penetrationstestning följer en definierad metodik. Vi använder ramverk baserade på PTES (Penetration Testing Execution Standard) och OWASP Testing Guide, anpassade till den specifika miljöns risk- och hotprofil.
Fas 1: Planering och scope-definition
Innan en enda nätverksförfrågan skickas definieras testets omfattning, regler och avgränsningar. Det innebär:
- Scope: Vilka nätverkssegment, system och tjänster inkluderas?
- Rules of engagement: Vilka tekniker är tillåtna? Får testaren exfiltrera data eller bara bevisa åtkomst?
- Tidsfönster: Testas under kontorstid, utanför kontorstid, eller båda?
- Eskaleringsvägar: Vem kontaktas om testaren råkar orsaka driftstörning?
- Startpunkt: Insiderscenario (anställdkonto), komprometterad arbetsstation, eller fysisk access?
Planeringsfasen avgör testets trovärdighet. Ett test utan tydligt scope ger otolkbara resultat.
Fas 2: Rekognosering och kartläggning
Testaren kartlägger den interna miljön med passiva och aktiva metoder:
- Passiv rekognosering: DNS-uppslag, NetBIOS-uppräkning, LLMNR/NBT-NS-sniffning för att fånga broadcast-trafik
- Aktiv skanning: Nmap-skanningar mot definierade subnät, tjänstidentifiering, OS-fingerprinting
- Active Directory-uppräkning: BloodHound-analys för att kartlägga behörighetsgrafer, group policy-objekt och trust-relationer
I den här fasen bygger testaren en bild av nätverkets topologi, identifierar högvärdiga mål (domänkontrollanter, filservrar, databaser) och hittar de mest sannolika attackvägarna.
Fas 3: Exploatering och privilegieeskalering
Här testas identifierade sårbarheter aktivt. Typiska tekniker inkluderar:
- Kerberoasting: Begär service tickets för service-konton och knäck dem offline
- NTLM relay: Fånga NTLM-autentisering och vidarebefordra den till andra tjänster
- Lokal privilegieeskalering: Utnyttja felkonfigurerade tjänster, saknade patchar eller osäkra filbehörigheter
- Token impersonation: Stjäl delegerade tokens för att agera som högre privilegierade användare
Varje lyckad exploatering dokumenteras med beviskedja: skärmdumpar, loggar och exakta kommandon.
Fas 4: Lateral rörelse och måluppfyllelse
Med eskalerade privilegier rör sig testaren genom nätverket mot de definierade målen — exempelvis åtkomst till kunddata, finansiella system eller produktionsmiljöer. Det här steget avslöjar om organisationens detektionsförmåga fungerar: triggar SOC:et larm? Reagerar EDR-verktyget?
Fas 5: Rapportering och åtgärdsplan
Rapporten är testets mest värdefulla leverans. Den ska innehålla:
- Exekutiv sammanfattning: Affärspåverkan i klartext för ledningsgruppen
- Teknisk detaljrapport: Varje sårbarhet med CVSS-poäng, beviskedja och reproducerbarhet
- Attacknarrativ: Hela kedjan från initial access till måluppfyllelse, visualiserad
- Prioriterad åtgärdslista: Vad som ska fixas först baserat på faktisk risk, inte bara CVSS
Regulatoriska krav: NIS2 och ISO/IEC 27001
NIS2-direktivet
NIS2-direktivet, som trädde i kraft i EU under 2024–2025, ställer explicita krav på att väsentliga och viktiga entiteter ska vidta proportionerliga tekniska och organisatoriska åtgärder för att hantera cybersäkerhetsrisker. Penetrationstestning nämns inte med exakt namn i direktivtexten, men kravet på regelbunden utvärdering av säkerhetsåtgärdernas effektivitet (Artikel 21.2e) gör det i praktiken nödvändigt.
Svenska organisationer inom sektorer som energi, transport, hälso- och sjukvård, digital infrastruktur och offentlig förvaltning omfattas. Att enbart förlita sig på automatiserade skanningar räcker inte för att demonstrera att ni har utvärderat effektiviteten av era säkerhetsåtgärder.
ISO/IEC 27001
ISO/IEC 27001:s kontrollmål A.12.6 (Technical vulnerability management) och A.18.2.3 (Technical compliance review) kräver systematisk identifiering och hantering av tekniska sårbarheter. En intern penetrationstestning adresserar båda kontrollmålen direkt och genererar den dokumentation som krävs vid certifieringsrevision.
Praktisk compliance-mappning
| Krav | Sårbarhetsskanning | Intern penetrationstest | Kommentar |
|---|---|---|---|
| NIS2 Art. 21.2e (effektivitetsutvärdering) | Delvis | Ja | Kräver bevisad testning, inte bara identifiering |
| ISO 27001 A.12.6 | Ja | Ja | Skanning räcker för identifiering, inte validering |
| ISO 27001 A.18.2.3 | Delvis | Ja | Teknisk granskning kräver djupare testning |
| GDPR Art. 32 (tekniska åtgärder) | Delvis | Ja | Penetrationstest demonstrerar adekvat säkerhetsnivå |
Vanliga verktyg och ramverk
Vi tar inte ställning för specifika kommersiella produkter, men dessa verktyg förekommer i praktiskt taget varje intern testning:
- BloodHound / SharpHound: Kartläggning av Active Directory-behörighetsgrafer — avgörande för att identifiera attackvägar mot domänadmin
- Impacket: Python-bibliotek för nätverksprotokoll, inklusive NTLM relay och Kerberos-attacker
- CrackMapExec / NetExec: Automatiserad uppräkning och exploatering av Windows-nätverk
- Nmap: Portskanning och tjänsteidentifiering
- Responder: LLMNR/NBT-NS/mDNS-poisoning för att fånga autentiseringsuppgifter
- Metasploit Framework: Modulärt ramverk för exploatering och post-exploitation
Verktygen är offentligt tillgängliga. Det som skiljer ett professionellt penetrationstest från ett amatörförsök är inte verktygen utan förmågan att kombinera dem i en koherent attackkedja och tolka resultaten i ett affärskritiskt sammanhang.
Hur ofta och vem ska testa?
Frekvens
Minimikravet för de flesta organisationer är en gång per år. Men den frekvensen förutsätter en relativt stabil miljö. Testa oftare om ni:
- Genomfört en molnmigrering eller hybridimplementering
- Slagit ihop nätverk efter ett förvärv
- Gjort väsentliga förändringar i Active Directory-strukturen
- Lanserat nya kritiska applikationer
Intern kontra extern testare
Interna säkerhetsteam har djup kunskap om miljön men lider av hemmablindhet. Externa testare saknar kontextkunskap men ser saker med fräscha ögon. Den bästa strategin kombinerar båda: intern kontinuerlig testning kompletterad med externa penetrationstester minst årligen.
NIS2 och ISO 27001 förutsätter i praktiken oberoende testning, vilket stärker argumentet för att anlita externa specialister — åtminstone för den formella årliga testningen.
Åtgärder efter testningen
Ett penetrationstest utan uppföljning är bortkastade pengar. Så hanterar ni resultaten:
Inom en vecka: Åtgärda kritiska sårbarheter som medger omedelbar domänkompromittering (t.ex. Kerberoasting av service-konton med svaga lösenord).
Inom en månad: Implementera nätverkssegmentering som faktiskt fungerar, stäng av NTLM där det inte behövs, aktivera LDAP signing och channel binding.
Inom ett kvartal: Genomför härdning av Active Directory baserat på testresultaten, implementera tiered access-modell, och verifiera att EDR-verktyget faktiskt larmar på de tekniker som testaren använde.
Kontinuerligt: Integrera lärdomarna i er Cloud FinOps-strategi och säkerhetsbudget. Säkerhet är inte en engångsinvestering utan en löpande driftskostnad.
Vanliga frågor
Hur ofta bör vi genomföra interna penetrationstester?
Minst årligen, men kvartalsvis för organisationer med hög risknivå eller krav enligt NIS2. Testa även efter större infrastrukturändringar — nya AD-domäner, migreringar till molnet eller uppköp som leder till nätverkssammanfogning. Frekvensen beror på hotbilden, men årliga tester är ett absolut minimum.
Vad kostar ett internt penetrationstest?
Prislappen varierar kraftigt beroende på nätverkets storlek, antal segment och testdjup. Räkna med 80 000–350 000 SEK för en medelstororganisation. Summan kan verka hög, men den bleknar i jämförelse med kostnaden för ett dataintrång som hade kunnat förebyggas.
Kan vi göra interna penetrationstester själva?
Delvis. Automatiserade skanningar och grundläggande testning kan göras internt med verktyg som BloodHound och Nessus. Men en fullständig penetrationstestning kräver extern expertis för att undvika hemmablindhet och för att uppfylla regulatoriska krav på oberoende testning.
Vad är skillnaden mellan penetrationstest och red team-övning?
Ett penetrationstest har ett avgränsat scope och testar specifika system under en definierad tidsperiod. En red team-övning simulerar en avancerad hotaktör under veckor eller månader, med fokus på att testa hela organisationens förmåga att upptäcka och svara — inklusive SOC, processer och personal.
Uppfyller automatiserade skanningar NIS2-kraven?
Nej. NIS2-direktivet kräver att organisationer vidtar proportionerliga tekniska åtgärder för att hantera risker. Automatiserade skanningar identifierar kända sårbarheter men bevisar inte att de faktiskt kan exploateras. En kombination av skanning och manuell penetrationstestning krävs för att uppfylla kraven.
Relaterade artiklar
Om författaren
Group COO & CISO at Opsio
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.
