Opsio - Cloud and AI Solutions
8 min read· 1,944 words

Pentesting: komplett handbok för nybörjare 2026

Publicerad: ·Uppdaterad: ·Granskad av Opsios ingenjörsteam
Översatt från engelska och granskad av Opsios redaktion. Visa originalet →
Fredrik Karlsson

Group COO & CISO

Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments

Pentesting: komplett handbok för nybörjare 2026

Pentesting: komplett handbok för nybörjare 2026

Penetrationstestning – pentesting – innebär att säkerhetsexperter på uppdrag försöker bryta sig in i era system på samma sätt som en verklig angripare. Syftet är att hitta och verifiera sårbarheter innan någon obehörig gör det. Med NIS2-direktivets krav på aktiv riskhantering och den ökande komplexiteten i molnbaserade miljöer har pentesting gått från "bra att ha" till en fundamental del av varje svensk organisations säkerhetsprogram.

Viktiga slutsatser

  • Pentesting simulerar verkliga angrepp och avslöjar sårbarheter som automatiserade skanningar missar
  • NIS2-direktivet och GDPR gör regelbunden penetrationstestning till en de facto-nödvändighet för svenska organisationer
  • Fem faser – rekognosering, skanning, exploatering, post-exploatering och rapportering – utgör standarden
  • Intern pentesting avslöjar ofta allvarligare brister än extern, eftersom laterala rörelser sällan är begränsade
  • En bra pentestrapport ger prioriterade åtgärder med affärskontext, inte bara en lista CVE:er

Vad är pentesting – och vad är det inte?

Pentesting är en auktoriserad, metodisk process där säkerhetsspecialister aktivt försöker ta sig in i system, nätverk och applikationer. Det handlar inte om att köra ett verktyg och skicka en automatgenererad PDF. En kvalificerad pentestare tänker som en angripare: identifierar ingångspunkter, kedjar ihop sårbarheter och eskalerar åtkomst tills det går att visa konkret affärspåverkan.

Det som skiljer pentesting från en enkel sårbarhetsskanning är just exploateringsfasen. Skannern säger "den här porten är öppen och tjänsten har en känd CVE". Pentestaren visar att CVE:n faktiskt leder till root-åtkomst på databasservern, och att databasen innehåller 400 000 kundposter. Den skillnaden – mellan teoretisk risk och bevisad påverkan – är avgörande för att ledningsgrupper ska förstå var investeringar behövs.

Från Opsios SOC ser vi dagligen hur organisationer som aldrig genomfört en ordentlig pentest överraskas av trivialiteter: standardlösenord på administrativa gränssnitt, öppna S3-buckets, service accounts med domänadmin-behörighet. Saker som en erfaren pentestare hittar inom den första timmen.

Pentesting kontra sårbarhetsskanning – en avgörande skillnad

Förvirringen mellan dessa två är vanlig, men kostsam. Här är en direkt jämförelse:

AspektSårbarhetsskanningPentesting
MetodAutomatiserad, signaturbaseradManuell + verktyg, kreativ exploatering
DjupBred yta, grund analysFokuserat djup, kedjad exploatering
FrekvensKontinuerlig / veckovisPeriodisk (kvartals-/årsvis)
ResultatLista med CVE:er och CVSS-poängBevisade attackvägar med affärspåverkan
FalsklarmHög andelLåg (allt verifieras manuellt)
KompetenskravOperatör/verktygskunskapOffensiv säkerhetsexpertis
KostnadLåg per körningHögre, men högre informationsvärde

Vår rekommendation: kör automatiserad sårbarhetsskanning kontinuerligt som hygienfaktor, och komplettera med manuell pentesting minst en gång per år – eller vid varje större förändring i infrastrukturen.

Kostnadsfri experthjälp

Vill ni ha expertstöd med pentesting: komplett handbok för nybörjare 2026?

Våra molnarkitekter hjälper er med pentesting: komplett handbok för nybörjare 2026 — från strategi till implementation. Boka ett kostnadsfritt 30-minuters rådgivningssamtal utan förpliktelse.

Solution ArchitectAI-specialistSäkerhetsexpertDevOps-ingenjör
50+ certifierade ingenjörerAWS Advanced Partner24/7 support
Helt kostnadsfritt — ingen förpliktelseSvar inom 24h

De fem faserna i en pentesting-insats

Strukturerad pentesting följer en beprövad metodik. De vanligaste ramverken – OWASP Testing Guide, PTES (Penetration Testing Execution Standard) och NIST SP 800-115 – delar in arbetet i fem huvudfaser.

1. Rekognosering (Reconnaissance)

Före det första "anfallet" spenderar en pentestare betydande tid på informationsinsamling. Denna fas delas i passiv och aktiv rekognosering:

Passiv rekognosering innebär att samla öppet tillgänglig information utan att direkt kontakta målets system: DNS-poster, WHOIS-data, LinkedIn-profiler på anställda, läckta credentials i databaser, certifikattransparensloggar och publicerade GitHub-repon. Verktyg som Shodan, Censys och theHarvester är standard.

Aktiv rekognosering innebär direkt interaktion med målets system: portskanning (Nmap), tjänsteidentifiering, banner grabbing och DNS-zonöverföringsförsök. Här börjar organisationens IDS/IPS potentiellt att reagera – vilket i sig är en testpunkt.

Från Opsios perspektiv: den information angripare hittar under rekognosering speglar er exponerade attackyta. Vi rekommenderar att ni själva regelbundet gör OSINT-genomgångar (Open Source Intelligence) av er organisation. Ni blir ofta förvånade över vad som ligger öppet.

2. Skanning och sårbarhetskartläggning

Med rekognoseringens data bygger pentestaren en detaljerad bild av målets tekniska landskap. Automatiserade skannrar som Nessus, Qualys eller OpenVAS identifierar kända sårbarheter, medan manuell analys letar efter logikfel och konfigurationsbrister.

Här kartläggs exempelvis:

  • Tjänster som körs på öppna portar och deras versioner
  • Webbapplikationers teknologistack (CMS, ramverk, bibliotek)
  • Autentiseringsmekanismer och deras styrka
  • API-endpoints och deras åtkomstkontroll
  • Molnkonfigurationer: publika snapshots, felkonfigurerade IAM-roller, exponerade metadata-tjänster

3. Exploatering

Kärnan i pentestingen. Här försöker testaren aktivt utnyttja identifierade sårbarheter. Det kan handla om:

  • Webbapplikationsattacker: SQL-injection, XSS, SSRF, insecure deserialization
  • Nätverksattacker: Man-in-the-middle, LLMNR/NBT-NS poisoning, relay-attacker
  • Autentiseringsattacker: Password spraying, credential stuffing, Kerberoasting
  • Molnspecifika attacker: IMDS-exploatering (Instance Metadata Service), IAM-policy-eskalering, cross-account-åtkomst

Verktyg som Metasploit, Burp Suite, BloodHound och Impacket är branschstandard, men en skicklig pentestare skriver ofta egen kod för att kringgå specifika skydd.

En viktig poäng: exploatering sker alltid kontrollerat. Målet är att bevisa att åtkomst är möjlig, inte att orsaka skada. Scope, regler och eskaleringsrutiner definieras noggrant i ett avtal (Rules of Engagement) innan arbetet börjar.

4. Post-exploatering och lateral rörelse

När initial åtkomst är etablerad undersöker pentestaren vad som faktiskt går att uppnå inifrån. Denna fas avslöjar ofta de mest affärskritiska riskerna:

  • Privilegieeskalering: Kan en vanlig användare bli domänadmin?
  • Lateral rörelse: Går det att nå andra system, segment eller miljöer?
  • Dataexfiltrering: Går det att komma åt och flytta ut känslig data utan att trigga larm?
  • Persistens: Kan angriparen behålla åtkomst även om den initiala sårbarheten patchas?

Opsios SOC-analytiker ser regelbundet att organisationer har hyfsad perimetersäkerhet men nästan obefintlig segmentering internt. En pentestare som tar sig in via en sårbar webbapplikation kan ofta röra sig fritt till Active Directory, ekonomisystem och kunddata. Det är precis den insikten som motiverar investeringar i Zero Trust-arkitektur och mikrosegmentering.

5. Rapportering och åtgärdsplanering

En pentestrapport som bara listar CVE:er och CVSS-poäng är i praktiken värdelös. En bra rapport innehåller:

  • Executive summary för ledningsgruppen: affärsrisk på begriplig svenska
  • Teknisk detaljredovisning för IT-teamet: steg-för-steg-beskrivning av varje attackväg
  • Prioriterade åtgärder baserade på faktisk exploaterbarhet, inte teoretisk allvarlighetsgrad
  • Bevis: Skärmbilder, loggutdrag, exfiltrerade testdata
  • Mappning mot ramverk: NIST CSF, ISO 27001, NIS2-krav

Rapporten bör mynna ut i en workshop där pentestarna går igenom fynden tillsammans med ert team. Dokumentation utan dialog leder sällan till åtgärd.

Typer av pentesting

Extern pentesting

Testar era internetexponerade system: webbapplikationer, e-posttjänster, VPN-gateways, DNS-servrar och molnresurser. Detta simulerar den mest uppenbara attackvektorn – en angripare utan förkunskap som söker en väg in.

Intern pentesting

Simulerar en angripare som redan har initial åtkomst, exempelvis via en komprometterad arbetsstation, en phishing-attack eller en illojal medarbetare. Intern pentesting avslöjar nästan alltid allvarligare brister än extern testning, eftersom de flesta organisationer saknar tillräcklig intern segmentering.

Webbapplikationspentesting

Fokuserar på applikationslagret och testar mot OWASP Top 10 och applikationsspecifik logik. Särskilt viktigt för SaaS-bolag, e-handel och organisationer med kundportaler.

Molnpentesting

Testar konfiguration och säkerhet i AWS, Azure eller GCP. Fokuserar på IAM-policyer, nätverkskonfiguration, lagringsåtkomst och tjänstespecifika risker. AWS tillåter sedan 2019 pentesting av egna resurser utan förhandsgodkännande, och Azure har liknande policy – men ni måste förstå er sida av shared responsibility-modellen.

Molnsäkerhet hos Opsio

Black box, grey box och white box

ModellPentestaren vetSimulerar
Black boxInget om målets interna strukturExtern angripare utan förkunskap
Grey boxDelvis information (t.ex. inloggningsuppgifter, nätverksdiagram)Angripare med viss insiderinformation
White boxFull tillgång till källkod, arkitekturdokumentation, credentialsMaximalt djup – hittar flest sårbarheter per timme

Opsios rekommendation: grey box ger bäst avkastning för de flesta organisationer. Ni slipper betala för att pentestaren ska spendera dagar på rekognosering som inte testar era tekniska kontroller, men behåller realismen i testet.

Regulatoriska krav som driver pentesting i Sverige

NIS2-direktivet

NIS2, som trädde i kraft inom EU 2024, ställer explicita krav på riskhantering och incidentrapportering för väsentliga och viktiga entiteter. Penetrationstestning nämns inte ordagrant som ett krav, men direktivets krav på "lämpliga och proportionella tekniska åtgärder" och "testning av säkerhetsåtgärdernas effektivitet" gör pentesting till den mest direkta metoden att uppfylla artikelkraven.

GDPR och Integritetsskyddsmyndigheten (IMY)

GDPR:s artikel 32 kräver att personuppgiftsansvariga implementerar "ett förfarande för att regelbundet testa, undersöka och utvärdera effektiviteten hos de tekniska och organisatoriska åtgärder som ska säkerställa behandlingens säkerhet." IMY har i tillsynsbeslut pekat på bristande testning som en faktor vid sanktionsavgifter.

SOC 2 och ISO 27001

Båda ramverken förväntar sig regelbunden oberoende säkerhetstestning. ISO 27001:s kontroll A.8.8 (hantering av tekniska sårbarheter) och SOC 2:s CC7.1 (detektion av konfigurationsförändringar) stärks markant av dokumenterad pentesting.

Managerade molntjänster

Verktyg som varje pentestare bör känna till

Här är de verktyg vi på Opsio ser våra offensiva team och partners använda mest frekvent:

  • Nmap – portskanning och tjänsteidentifiering
  • Burp Suite Professional – webbapplikationstestning
  • Metasploit Framework – exploateringsramverk
  • BloodHound – Active Directory-analys och attackvägsvisualisering
  • CrackMapExec / NetExec – nätverksautentiseringstestning
  • Nuclei – mallbaserad sårbarhetsskanning
  • ScoutSuite / Prowler – molnkonfigurationsanalys (AWS, Azure, GCP)
  • Hashcat – lösenordsknäckning (offline)

Verktygen är viktiga, men kompetensen att tolka resultat och kedja ihop fynd är det som skiljer en automatiserad rapport från en genuint insiktsfull pentest.

Vanliga misstag vi ser från Opsios SOC

1. Pentesting som engångshändelse. En pentest vart tredje år ger en ögonblicksbild som snabbt blir irrelevant. Infrastruktur och hot förändras kontinuerligt.

2. Scopet är för snävt. Att bara testa webbapplikationen men ignorera API:erna, Active Directory och molnkonfigurationen ger en falsk känsla av trygghet.

3. Resultaten hamnar i en byrålåda. Om rapporten inte leder till åtgärder inom 30 dagar har ni kastat pengar i sjön. Vi rekommenderar att koppla pentestfynd direkt till Jira-tickets eller motsvarande arbetsflöde.

4. Ingen uppföljande omtest. Efter att åtgärder implementerats bör de verifieras genom ett riktat omtest. Annars vet ni inte om patchen faktiskt fungerar.

5. Otillräckliga Rules of Engagement. Utan tydligt scope, eskaleringsrutiner och juridiskt avtal riskerar ni både juridiska problem och oavsiktlig driftpåverkan.

Managerad DevOps

Så väljer ni rätt pentesting-partner

Några frågor att ställa till potentiella leverantörer:

  • Vilka certifieringar har testarna? OSCP (Offensive Security Certified Professional) är branschens guldstandard. OSWE, CRTO och GPEN är relevanta tillägg.
  • Hur ser en exempelrapport ut? Be om en anonymiserad rapport – kvaliteten där speglar vad ni får.
  • Vad ingår i scope-diskussionen? En seriös leverantör lägger tid på att förstå er verksamhet, inte bara er infrastruktur.
  • Genomför ni manuell testning eller mestadels automatiserad skanning? Fråga rakt ut hur fördelningen ser ut.
  • Erbjuder ni omtest? Det bör ingå i priset eller erbjudas till kraftigt reducerat pris.

Molnmigrering

Pentesting som del av en bredare säkerhetsstrategi

Pentesting är kraftfullt men inte tillräckligt i isolation. Det fungerar bäst som en komponent i en mogen säkerhetsarkitektur:

  • Kontinuerlig sårbarhetsskanning fångar kända brister mellan pentestcykler
  • SOC-övervakning (24/7) detekterar och responderar på aktiva hot i realtid
  • Security Awareness-träning minskar risken att anställda blir den initiala attackvektorn
  • Incidentresponsplan säkerställer att ni vet vad ni gör när (inte om) ett intrång sker
  • FinOps och Cloud Governance förhindrar att molnkonfigurationer glider iväg och skapar nya attackytor

Cloud FinOps

Pentesting ger er bevisen. Resten av säkerhetsprogrammet ger er förmågan att agera på dem.

Vanliga frågor

Hur ofta bör en organisation genomföra pentesting?

Minst årligen för produktionsmiljöer, och alltid vid större förändringar som nya applikationer, infrastrukturbyten eller migrering till molnet. Organisationer som omfattas av NIS2 eller PCI DSS kan behöva kvartalsvis testning. Opsios rekommendation: koppla pentest-cykeln till er release-pipeline så att kritiska förändringar aldrig går live otestade.

Vad kostar en pentesting-insats?

Priset varierar kraftigt beroende på scope – från runt 50 000 SEK för en avgränsad webbapplikation till flera hundra tusen kronor för en fullständig red team-övning mot ett företagsnätverk. Det avgörande är att definiera scopet noggrant innan, annars betalar ni för bredd ni inte behöver eller missar djup där det verkligen krävs.

Kan vi pentesta vår molnmiljö i AWS eller Azure?

Ja, men med viktiga förbehåll. AWS tillåter pentesting mot egna resurser utan förhandsgodkännande sedan 2019, medan Azure har liknande policy. Däremot måste ni förstå ansvarsgränserna i shared responsibility-modellen – ni testar er konfiguration och kod, inte leverantörens underliggande infrastruktur.

Vad är skillnaden mellan pentesting och red teaming?

Pentesting fokuserar på att hitta och verifiera tekniska sårbarheter inom ett definierat scope och tidsramar. Red teaming är bredare – det simulerar en verklig hotaktör över veckor eller månader, inkluderar social engineering och fysisk åtkomst, och testar hela organisationens detektions- och responsförmåga, inte bara tekniken.

Räcker det med automatiserad sårbarhetsskanning istället för manuell pentesting?

Nej. Automatiserade verktyg hittar kända sårbarheter med kända signaturer, men missar logikfel, kedjade attacker och konfigurationsbrister som kräver mänsklig kreativitet. Sårbarhetsskanning är ett utmärkt komplement – använd det kontinuerligt – men det ersätter inte den manuella pentestens förmåga att tänka som en angripare.

Om författaren

Fredrik Karlsson
Fredrik Karlsson

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.