Microsofts regler för penetrationstestning

Innan ni planerar ett pentest måste ni förstå vad Microsoft tillåter. Sedan 2017 behöver ni inte längre skicka in en förhandsansökan för att testa de flesta Azure- och M365-tjänster. Microsofts Cloud Penetration Testing Rules of Engagement gäller dock fortfarande.

Tillåtet:

• Testa er egna tenant – Entra ID, Exchange Online, SharePoint, Teams, OneDrive
• Social engineering mot era egna användare (phishing-simuleringar)
• Web-applikationstestning mot era egna appar

Förbjudet:

• DDoS-attacker mot Microsofts infrastruktur
• Test mot andra kunders resurser (shared infrastructure)
• Försök att bryta kryptering eller kompromittera Microsofts egen infrastruktur
• Port scanning av Microsofts IP-ranges i stor skala

Brott mot dessa regler kan leda till att er tenant stängs av. Vi på Opsio ser ibland kunder som engagerat testare utan kunskap om dessa begränsningar – det skapar onödig risk och kaos.

De fem attackytorna ni bör testa

1. Entra ID – identitet och åtkomstkontroll

Entra ID (tidigare Azure AD) är hjärtat i all M365-åtkomst. En angripare som komprometterar en Global Administrator-identitet äger i praktiken hela er digitala verksamhet.

Vad testaren undersöker:

• Conditional Access-policyer: Finns undantag som tillåter inloggning utan MFA? Testaren försöker autentisera via äldre protokoll (POP3, IMAP) som ofta saknar Conditional Access-skydd.
• App-registreringar och Enterprise Apps: Överprivilegierade servicekonton med Application-behörigheter (inte delegerade) kan läsa all e-post i organisationen utan att någon användare godkänt det.
• Token-hantering: Kan en stulen refresh token användas för att bibehålla åtkomst även efter lösenordsbyte?
• Rollhantering: Hur många Global Admins finns? Opsio rekommenderar max två break-glass-konton – vi ser regelbundet organisationer med 10–15 stycken.

2. Exchange Online – e-post och kalendrar

E-post är fortfarande den primära attackvektorn. Enligt CNCF Annual Survey och branschobservationer från vårt eget SOC börjar en majoritet av alla lyckade intrång med kompromitterad e-post.

Testfokus:

• Mail flow-regler som vidarebefordrar e-post externt (en klassiker vid Business Email Compromise)
• Delegerade postlåderättigheter som inte längre behövs
• DMARC/SPF/DKIM-konfiguration och hur den hanterar spoofing
• E-postbaserad phishing-simulering mot utvalda målgrupper

3. SharePoint Online och OneDrive

SharePoint är ofta organisationens största datalager – och det mest felkonfigurerade. Molnsäkerhet

Vanliga fynd:

• "Anyone"-delningslänkar som exponerar känsliga dokument till hela internet
• Sajtbehörigheter som ärvts felaktigt och ger bred åtkomst till känsliga projektdokument
• Externa gästanvändare med kvarglömd åtkomst till interna team-sajter
• Saknade DLP-policyer för personnummer, kreditkortsnummer och andra känsliga datatyper

4. Teams och samarbetsverktyg

Teams är en ofta förbisedd attackyta. Varje Teams-kanal har en underliggande SharePoint-sajt, och filer som delas i chatten lagras i användarens OneDrive.

Testscenarier:

• Kan en extern gästanvändare eskalera åtkomst till kanaler de inte bör se?
• Tillåter organisationen tredjepartsappar i Teams som begär omfattande behörigheter?
• Går det att exfiltrera data via Teams-webhooks?

5. Power Platform och tredjepartsintegrationer

Power Automate-flöden och Power Apps kopplar ofta M365-data till externa tjänster. En felkonfigurerad connector kan läcka data utan att det syns i standardloggar.

Testaren undersöker:

• Vilka anslutningar finns till externa tjänster och vilka data flödar?
• Kan en vanlig användare skapa flöden som exporterar känslig data?
• Finns DLP-policyer i Power Platform som begränsar vilka connectorer som får kombineras?

Praktisk metodik – så genomförs testet

Fas 1: Scope och förutsättningar (vecka 1)

Definiera tydligt vad som ska testas. Ett pentest utan tydligt scope ger otydliga resultat. Vi på Opsio rekommenderar att börja med följande frågor:

• Black box, grey box eller white box? Grey box är oftast mest kostnadseffektivt för M365 – testaren får ett vanligt användarkonto och försöker eskalera därifrån.
• Vilka tjänster ingår? Entra ID + Exchange + SharePoint är en rimlig startpunkt.
• Vilka användare är i scope för social engineering? Begränsa till utvalda grupper för att undvika onödigt produktionsstörning.
• Vem äger testmiljön? Klargör ansvar så att testet inte blockeras av interna processer.

Fas 2: Rekognosering och enumeration (vecka 2)

Testaren kartlägger er M365-tenant utifrån. Verktyg som AADInternals, ROADtools och o365creeper ger insyn i:

• Vilka domäner som är federerade
• Om legacy-autentisering är tillåtet
• Vilka tjänster som är exponerade
• Vilka användare och grupper som finns (om enumeration inte är blockerat)

Fas 3: Aktiv testning (vecka 2–3)

Här börjar det egentliga penetrationstestet. Testaren använder samma tekniker som verkliga hotaktörer:

• Password spraying mot vanliga lösenord (försiktigt, under lockout-trösklarna)
• Token theft via phishing eller device code phishing
• Privilege escalation genom felkonfigurerade app-behörigheter
• Data discovery i SharePoint, OneDrive och Teams
• Lateral movement mellan tjänster via OAuth-tokens

Fas 4: Rapportering och åtgärdsplan (vecka 4)

Rapporten är det viktigaste leveransobjektet. En rapport som bara listar CVE-nummer utan affärskontext är värdelös för beslutsfattare.

En bra rapport innehåller:

• Executive summary på max en sida – läsbar för CISO och VD
• Varje fynd med: beskrivning, bevissteg (screenshots), allvarlighetsgrad (CVSS), affärspåverkan och konkret remediering
• En prioriterad åtgärdslista med föreslagna ansvariga ägare och tidslinje

Managerade molntjänster

Vanliga misstag vi ser från Opsios SOC

1. Pentest som engångshändelse. Organisationer som testar en gång och sedan glömmer bort det i tre år. Er M365-miljö förändras ständigt – nya appar, nya användare, nya konfigurationer. Testa minst årligen.

2. Scope som är för brett. Att försöka testa allt på en gång ger ytliga resultat. Bättre att testa Entra ID på djupet än att skrapa på ytan av 15 tjänster.

3. Ingen åtgärdsuppföljning. Hälften av värdet i ett pentest ligger i vad som händer efteråt. Utan strukturerad uppföljning hamnar rapporten i en låda. Vi rekommenderar en remediering-sprint inom 30 dagar och ett verifieringstest inom 90 dagar.

4. Testaren saknar M365-kompetens. Pentestare som är duktiga på nätverksintrång är inte automatiskt bra på att testa molnmiljöer. Kräv dokumenterad erfarenhet av Entra ID, Exchange Online och SharePoint.

5. Ignorera Conditional Access-undantag. Det vanligaste konfigurationsfelet vi ser i Opsios NOC är Conditional Access-policyer som har "All users" som target men med undantag för servicekonton – och det är precis de kontona en angripare siktar på.

Regulatoriskt perspektiv: NIS2 och GDPR

NIS2-direktivet, som trädde i kraft i EU under 2024, ställer explicita krav på att väsentliga och viktiga entiteter ska genomföra regelbundna riskbedömningar och testa sin cybersäkerhet. Penetrationstestning är inte nämnt vid namn, men det är det mest effektiva sättet att uppfylla kraven på "lämpliga och proportionella tekniska och organisatoriska åtgärder" (artikel 21).

GDPR artikel 32 kräver att personuppgiftsansvariga vidtar lämpliga säkerhetsåtgärder, inklusive "förfaranden för att regelbundet testa, bedöma och utvärdera effektiviteten i de tekniska och organisatoriska åtgärderna". Integritetsskyddsmyndigheten (IMY) har i flera tillsynsbeslut lyft fram att avsaknad av regelbunden säkerhetstestning kan utgöra en brist i efterlevnaden.

Molnmigrering

Verktyg och ramverk att känna till

Dessa verktyg ersätter inte en kompetent testare – de är instrumenten testaren använder.

Vad händer efter testet?

Ett pentest som inte leder till förändring är en kostnad utan avkastning. Så här ser en effektiv åtgärdsprocess ut:

1. Dag 1–3: Gå igenom rapporten med säkerhetsteam och systemägare. Förstå varje fynd.

2. Dag 3–7: Prioritera och tilldela ägare. Kritiska fynd (CVSS 9+) bör ha en workaround inom 48 timmar.

3. Dag 7–30: Genomför remediering-sprint. Åtgärda konfigurationsfel, stäng överprivilegierade konton, implementera saknade Conditional Access-policyer.

4. Dag 60–90: Verifieringstest av de mest kritiska fynden. Har åtgärderna faktiskt stängt attackvägen?

5. Löpande: Integrera insikterna i er säkerhetsövervakning. Opsios SOC kan monitorera specifika indikatorer som identifierats under testet. Managerad DevOps

Vanliga frågor

Tillåter Microsoft penetrationstestning av Microsoft 365?

Ja, sedan 2017 behöver du inte längre förhandsansöka för att testa de flesta Azure- och M365-tjänster. Du måste dock följa Microsofts Rules of Engagement – exempelvis får du inte testa mot andra kunders resurser, utföra DDoS eller försöka bryta kryptering. Läs alltid den aktuella versionen av Microsofts Cloud Penetration Testing Rules of Engagement innan ni startar.

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

Minst en gång per år som baslinje, plus efter större konfigurationsändringar – exempelvis ny Conditional Access-policy, integration av tredjepartsappar eller migrering av nya arbetsbelastningar. Organisationer som omfattas av NIS2 eller hanterar känsliga personuppgifter bör överväga kvartalsvis testning av de mest exponerade ytorna.

Vad kostar ett pentest av Microsoft 365?

En fokuserad M365-test av Entra ID, Exchange Online och SharePoint tar typiskt 5–15 konsultdagar beroende på miljöns storlek och scope. Räkna med 80 000–250 000 SEK för en seriös leverantör. Billigare alternativ som enbart kör automatiserade skanningar ger sällan den djupa analys som avslöjar verkliga attackkedjor.

Vilka sårbarheter hittas oftast vid pentest av M365?

Opsios SOC ser tre återkommande fynd: överprivilegierade servicekonton i Entra ID, avsaknad av Conditional Access för äldre protokoll (IMAP/POP3) och felkonfigurerade delningspolicyer i SharePoint/OneDrive som exponerar data externt. Dessa är sällan sofistikerade – men de är precis vad angripare letar efter.

Kan vi pentesta M365 själva eller behöver vi en extern partner?

Intern testning med verktyg som Microsoft Secure Score, Maester och ScubaGear ger bra grundläggande hygien. Men ett fullvärdigt pentest kräver en oberoende testare som tänker som en angripare – inte som den som byggde miljön. Extern validering ger trovärdighet mot revisorer och uppfyller NIS2:s krav på oberoende säkerhetsgranskning. Cloud FinOps