Pentest kontra andra säkerhetsåtgärder

En av de vanligaste missuppfattningarna vi möter är att en sårbarhetsscanning räcker. Det gör den inte. Här är den konkreta skillnaden:

Pentestet fyller en specifik roll: det bevisar affärsrisken. Att veta att ni har en CVE med CVSS 9.8 är en sak. Att se en testare demonstrera hur den leder till full mailbox-åtkomst för VD:n är något helt annat – och det är den insikten som får säkerhetsbudgetar att frigöras.

Metodik: Så genomför vi ett Exchange-pentest

Fas 1 – Scope och hotprofilering

Allt börjar med att definiera scope. Ska testet omfatta on-premises Exchange, Exchange Online (M365), hybridkonfiguration eller hela kedjan inklusive federation? Scope avgör juridiska förutsättningar, testmetoder och kostnader.

Parallellt genomför vi CTI-driven hotprofilering (Cyber Threat Intelligence). Det innebär att vi kartlägger vilka hotaktörer som historiskt riktat sig mot er bransch och geografi. En svensk tillverkningsindustri har en annan hotbild än en fintech-startup – testet bör reflektera det.

Konkret innebär detta:

• Analys av relevanta MITRE ATT&CK-tekniker för Exchange-angrepp
• Identifiering av branschspecifika threat actors (t.ex. APT28 för myndigheter, FIN7 för detaljhandel)
• Definition av Rules of Engagement (RoE) – vad får testaren göra, vilka system är undantagna, kontaktvägar vid kritiska fynd

Fas 2 – Rekognosering och kartläggning

Testaren börjar med passiv rekognosering: DNS-uppslag, certifikatloggar (Certificate Transparency), OSINT mot publika endpoints. Målet är att kartlägga den exponerade ytan utan att generera trafik som triggar larm.

Därefter övergår vi till aktiv rekognosering:

• Enumeration av OWA, EWS, autodiscover och ActiveSync-endpoints
• Identifiering av Exchange-version och patchnivå via HTTP-headers och NTLM-information
• Kartläggning av e-postadresser och användarnamn via timing-attacker och LDAP-enumeration

Det här steget avslöjar ofta mer än organisationen tror. Vi har sett fall där autodiscover-konfigurationer läcker interna domännamn, eller där OWA exponerar Exchange-serverns exakta build-nummer – information som gör det trivialt att identifiera saknade patchar.

Fas 3 – Sårbarhetidentifiering och exploatering

Nu blir det konkret. Baserat på kartläggningen identifierar och validerar testaren sårbarheter:

Konfigurationsbrister:

• Svaga lösenordspolicyer på OWA (ingen lockout, ingen MFA)
• Felkonfigurerade transportregler som tillåter e-postspoofing
• Öppna SMTP-relays
• Saknad SPF/DKIM/DMARC-konfiguration

Kända CVE:er:

• ProxyLogon/ProxyShell/ProxyNotShell-kedjorna
• Deserialiseringsattacker mot Exchange PowerShell
• SSRF-sårbarheter (Server-Side Request Forgery)

Autentiseringsattacker:

• Password spraying mot OWA med organisationsspecifika ordlistor
• NTLM relay-attacker via Exchange-endpoints
• Kerberos-baserade attacker (Kerberoasting) mot Exchange-servicekonton

Varje sårbarhet som identifieras valideras genom kontrollerad exploatering. Testaren dokumenterar exakt hur exploateringen genomfördes, vilken data som var åtkomlig och hur långt lateral movement var möjlig. Molnsäkerhet

Fas 4 – Post-exploatering och lateral movement

Om testaren lyckas med initial exploatering undersöker vi hur långt det går att komma. Typiska post-exploateringssteg i en Exchange-miljö:

• Mailbox-åtkomst: Kan vi läsa andra användares e-post? Hur känslig data hittas?
• AD-eskalering: Kan Exchange-åtkomst användas för att eskalera till Domain Admin (t.ex. via Exchange Windows Permissions-gruppen)?
• Persistence: Kan vi sätta upp varaktig åtkomst som överlever patchning? (Transport rules, mailbox forwarding, WebShells)
• Dataexfiltrering: Hur mycket data kan vi extrahera utan att trigga DLP-larm?

Det här steget är ofta det mest ögonöppnande för organisationer. Att se hur en testare går från en enda stulna inloggning till full kontroll över mailflödet ger en helt annan riskförståelse än en lista med CVE-nummer.

Fas 5 – Rapportering och åtgärder

En pentestrapport som bara listar sårbarheter är värdelös. Vi levererar en rapport strukturerad för tre målgrupper:

1. Executive summary – affärsrisk i klartext, utan teknisk jargong

2. Teknisk rapport – varje sårbarhet med beviskedja, CVSS-poäng och reproduktionssteg

3. Åtgärdsplan – prioriterade rekommendationer med tidsramar: omedelbart (0–48h), kort sikt (1–4 veckor), strategiskt (1–6 månader)

Vi genomför alltid ett retest efter att kritiska sårbarheter åtgärdats – annars vet ni inte om fixen faktiskt fungerar. Managerade molntjänster

Regulatoriska krav: NIS2, GDPR och svensk lagstiftning

Pentest av Exchange är inte bara god praxis – det är i många fall ett regulatoriskt krav.

NIS2-direktivet (antaget i svensk lag via cybersäkerhetslagen som trädde i kraft 2025) ställer explicita krav på riskhantering och incidenthantering för väsentliga och viktiga entiteter. Regelbunden säkerhetstestning – inklusive penetrationstestning – är en central del av dessa krav. Organisationer som omfattas riskerar sanktionsavgifter vid bristande efterlevnad.

GDPR (artikel 32) kräver att personuppgiftsansvariga implementerar "lämpliga tekniska och organisatoriska åtgärder" proportionellt mot risken. Exchange-servrar som hanterar personuppgifter – vilket i princip alla gör – faller under detta krav. Integritetsskyddsmyndigheten (IMY) har i tillsynsbeslut lyft bristande teknisk testning som en faktor vid bedömning av sanktionsavgifter.

ISO/IEC 27001 (Annex A.8.8) och SOC 2 (Common Criteria) refererar båda till teknisk sårbarhetstestning som kontroll. Pentest är det mest konkreta sättet att visa att kontrollen är implementerad.

Vanliga misstag vi ser i produktion

Opsios SOC/NOC hanterar Exchange-miljöer dygnet runt. Här är de återkommande bristerna vi identifierar:

Patcheftersläpning. Exchange Cumulative Updates släpar efter med 2–3 versioner. Angripare vet exakt vilka CVE:er varje CU åtgärdar och skannar aktivt efter opatchade servrar.

MFA saknas på OWA. Förvånansvärt många organisationer kör OWA utan multifaktorautentisering. Password spraying mot OWA med vanliga svenska lösenord (årstid + årtal, företagsnamn + siffror) lyckas oftare än man vill tro.

Bristande segmentering. Exchange-servrar har ofta för breda nätverksbehörigheter. Om servern kan nå alla segment i nätverket kan en angripare använda den som språngbräda.

Ingen loggövervakning. Exchange genererar detaljerade loggar – men om ingen läser dem spelar det ingen roll. Utan SIEM-integration och aktiv övervakning kan en angripare operera i veckor utan att upptäckas. Managerad DevOps

Verktyg och ramverk

Ett Exchange-pentest använder en kombination av verktyg anpassade för Microsoft-ekosystemet:

Ramverk som OWASP Testing Guide, PTES (Penetration Testing Execution Standard) och NIST SP 800-115 ger strukturen. MITRE ATT&CK ger den hotaktörsbaserade kontexten – specifikt teknikerna under "Initial Access" (T1190, T1078) och "Collection" (T1114).

Exchange Online vs. on-premises: skillnader i pentest

Hybrid-miljöer – som fortfarande är normen för de flesta svenska medelstora företag – kräver att testet adresserar båda världarna:

On-premises: Full kontroll, testet kan omfatta OS-nivå, nätverkssegmentering, AD-integration och fysisk infrastruktur. Här finns de allvarligaste sårbarheterna – men också de enklaste att åtgärda internt.

Exchange Online (M365): Microsofts infrastruktur är utanför scope. Testet fokuserar istället på:

• Azure AD-konfiguration och Conditional Access-policyer
• OAuth-appregistreringar och behörigheter
• Delegerade behörigheter och service principals
• E-postflödesregler och connectors
• Data Loss Prevention (DLP) och informationsbarriärer

Hybrid: Här uppstår unika risker. Azure AD Connect-servern, ADFS-proxyer och hybrid mail-routing skapar nya attackvektorer som varken finns i en ren on-prem- eller molnmiljö. Vi har sett fall där hybridkonfigurationen i sig skapade privilegieeskaleringsvägar som inte existerade i någon av de enskilda miljöerna. Molnmigrering

Så bygger ni ett kontinuerligt testprogram

Ett enstaka pentest ger en ögonblicksbild. Verklig säkerhet kräver kontinuitet:

1. Årligt fullskaligt pentest – djupgående test med manuell exploatering, CTI-driven hotprofilering

2. Kvartalsvis automatiserad scanning – Nessus, Qualys eller liknande mot Exchange-endpoints

3. Kontinuerlig övervakning – SOC-integration med Exchange-loggar, anomalidetektering på OWA-inloggningar

4. Patch-validering – automatiserade tester efter varje CU/SU som verifierar att kända CVE:er är åtgärdade

5. Tabletop-övningar – scenariobaserade övningar där IT-team och ledning simulerar en Exchange-kompromittering

Flexeras State of the Cloud har konsekvent visat att säkerhet är en topprioritet vid molnadoption – men att gapet mellan ambition och praktisk testning ofta är stort. Pentest är det som överbryggar det gapet. Cloud FinOps

Vanliga frågor

Hur ofta bör vi pentesta vår Exchange-miljö?

Minst en gång per år som baslinje, men helst efter varje större uppgradering, konfigurationsändring eller patchcykel. Organisationer som omfattas av NIS2 bör överväga kvartalsvis testning. Det som avgör frekvensen är er hotbild, inte kalendern.

Kan vi pentesta Exchange Online eller bara on-premises?

Båda går att testa, men scopet skiljer sig. On-premises ger full kontroll över servermiljön. Exchange Online (Microsoft 365) kräver att testet fokuserar på konfiguration, åtkomstpolicyer, OAuth-flöden och federation – inte Microsofts infrastruktur. Opsio anpassar metodiken efter er deployment-modell.

Vad kostar ett pentest av Exchange?

Priset varierar beroende på scope, antal servrar, hybrid-komplexitet och om social engineering ingår. En riktad Exchange-testning för en medelstor organisation landar typiskt mellan 80 000 och 250 000 SEK. Avgörande är inte priset utan att rapporten ger åtgärdsbara rekommendationer.

Påverkar ett pentest vår dagliga e-postdrift?

Ett professionellt pentest genomförs med kontrollerade metoder som minimerar driftstörningar. Opsios SOC koordinerar testfönster med ert driftteam och övervakar miljön under hela testet. I sällsynta fall kan specifika exploateringstester orsaka kortvarig påverkan – det dokumenteras alltid i förväg i testplanen.

Räcker inte en vanlig sårbarhetsscanning?

Nej. Scanning identifierar kända CVE:er och felkonfigurationer men validerar inte om de faktiskt går att exploatera i er specifika miljö. Ett pentest visar kedjan – hur en angripare kombinerar flera svagheter till ett verkligt intrång. Det är skillnaden mellan att veta att dörren är gammal och att bevisa att den går att sparka in.