Metodik: hur ett SharePoint-pentest faktiskt går till

Fas 1 – Scope och regler

Innan ett enda paket skickas behöver scope definieras noggrant. Centrala frågor:

• On-prem, Online eller hybrid? Metodiken skiljer sig. On-prem öppnar för nätverksbaserade attacker; Online begränsas av Microsofts Rules of Engagement.
• Vilka siter och hubbar ingår? Testa inte allt – fokusera på siter som hanterar känslig data, HR-information, ledningsdokumentation och projektarkiv med extern delning.
• Autentiserade eller oautentiserade tester? I SharePoint Online är oautentiserad testning sällan meningsfull. De verkligt intressanta fynden kommer vid testning med en lågt privilegierad användare som försöker eskalera.
• Custom code? Kartlägg alla SPFx-lösningar, Power Automate-flöden och tredjepartsintegrationer som ingår i scope.

Fas 2 – Rekognosering och enumeration

Här kartlägger testaren miljön systematiskt:

• Tenant-enumeration: Identifiera siter, hubbar, termstore-taxonomi och anslutna Microsoft 365-grupper. Verktyg som o365creeper och Microsoft Graph API ger en bra startbild.
• Behörighetskartläggning: Analysera vem som har åtkomst till vad, var arvet är brutet och vilka delningslänkar som är aktiva. SharePoint Online Management Shell och PnP PowerShell är oumbärliga.
• API-enumeration: Identifiera exponerade REST-endpoints, Graph API-behörigheter och eventuella custom API:er bakom Azure Functions.
• SPFx-analys: Ladda ner och dekompilera SPFx-paket (.sppkg) för att granska JavaScript-koden efter hårdkodade hemligheter, osäkra API-anrop eller XSS-vektorer.

Fas 3 – Exploitation och verifiering

Det här är kärnan i pentestet – att visa vad som faktiskt kan utnyttjas, inte bara vad som teoretiskt är sårbart:

Behörighetseskalering är det vanligaste fyndet. Vi testar systematiskt:

• Kan en vanlig användare nå siter utanför sin avsedda åtkomst via direkt URL, sökning eller Graph API?
• Finns det delningslänkar av typen "Anyone with the link" på känsliga dokument?
• Kan en gästanvändare se mer än den site de bjudits in till?

Custom code-sårbarheter i SPFx-webparts följer ofta mönster vi känner igen från traditionell webbapptestning: XSS genom bristfällig inputvalidering, SSRF via server-side-anrop, eller exponerade API-nycklar i klientkod.

OAuth/samtyckes-attacker där testaren försöker få en användare att godkänna en illvillig app med breda Graph API-behörigheter. Det här är särskilt effektivt i miljöer som inte begränsat användarsamtycke i Azure AD.

Fas 4 – Rapportering och åtgärdsplan

En pentestrapport som bara listar CVE:er och CVSS-poäng är nästan värdelös. Vi strukturerar rapporter med:

• Exekutiv sammanfattning – vad innebär fynden för verksamheten, inte bara tekniken
• Attacknarrativ – steg-för-steg-beskrivning av hur testaren gick från lågt privilegierad användare till åtkomst av känslig data
• Fynd med risk och kontext – varje fynd bedöms utifrån er specifika miljö, inte bara generisk CVSS
• Konkreta åtgärdsrekommendationer med prioritering – vad ni ska fixa den här veckan vs. det här kvartalet

De fem vanligaste sårbarheterna vi hittar

Baserat på de SharePoint-pentester vi genomfört under de senaste två åren följer här de mest återkommande fynden:

1. Överbreda delningslänkar

"Anyone with the link"-inställningar som är aktiverade tenant-wide, ofta som en kvarglömd standard från migreringstillfället. Resultat: känsliga dokument som är åtkomliga för vem som helst med rätt URL.

2. Brutna behörighetsarv utan uppföljning

Administratörer bryter arvet på en site eller ett bibliotek för att ge en specifik grupp åtkomst, men glömmer att granska resultatet. Över tid ackumuleras direkta behörighetstilldelningar som ingen har översikt över.

3. SPFx-webparts med hårdkodade hemligheter

API-nycklar, connection strings eller bearer tokens som ligger i klartext i klientpaketets JavaScript. En angripare behöver bara öppna DevTools i webbläsaren.

4. Obegränsat Azure AD-samtycke

Användare kan själva godkänna tredjepartsappar som begär läsbehörighet till SharePoint via Graph API. En väl utformad phishing-kampanj ger angriparen fullständig läsåtkomst utan att kompromissa ett enda lösenord.

5. Bristfällig loggning och övervakning

SharePoint-auditloggen är aktiverad men ingen agerar på den. Massexport av dokument, behörighetsändringar på känsliga siter eller ovanliga Graph API-anrop triggar inga larm.

Regulatorisk kontext: NIS2 och GDPR

Organisationer som omfattas av NIS2-direktivet – och det gäller betydligt fler sedan den utvidgade tillämpningen – behöver kunna visa att de vidtar "lämpliga och proportionella tekniska och organisatoriska åtgärder". Penetrationstestning av system som hanterar verksamhetskritisk data är en av de mest konkreta sätten att uppfylla det kravet.

GDPR artikel 32 ställer krav på "ett förfarande för att regelbundet testa, undersöka och utvärdera effektiviteten hos tekniska och organisatoriska åtgärder". Ett pentest av SharePoint som hanterar personuppgifter är en direkt tillämpning av den artikeln.

Integritetsskyddsmyndigheten (IMY) har vid flera tillsynsbeslut pekat på bristande säkerhetstestning som en faktor vid bedömning av sanktionsavgifter. Att kunna visa dokumenterade pentester med åtgärdsuppföljning är en konkret riskmitigerande faktor.

Molnsäkerhet

Verktyg och teknisk stack

CISAs ScubaGear-verktyg förtjänar ett särskilt omnämnande. Det är gratis, open source och ger en baslinjekontroll av SharePoint Online-konfigurationen mot CISAs M365 Secure Configuration Baselines. Det ersätter inte ett manuellt pentest, men det fångar de mest uppenbara felkonfigurationerna.

Så väljer ni pentestleverantör

Inte alla pentestföretag har erfarenhet av SharePoint-specifik testning. Frågor att ställa:

• Har teamet testat SharePoint-miljöer förut? Be om anonymiserade exempel på SharePoint-specifika fynd.
• Kan de testa SPFx-webparts och Power Automate-flöden? Många testare stannar vid standardkonfigurationen.
• Hur hanterar de data? SharePoint innehåller ofta känslig verksamhetsdata. Säkerställ att testaren har processer för datahantering, NDA och eventuell bakgrundskontroll.
• Levererar de en åtgärdsuppföljning? En bra leverantör erbjuder en kostnadsfri verifieringssession efter att ni åtgärdat de kritiska fynden.

Managerade molntjänster

Från pentest till kontinuerlig säkerhet

Ett pentest är en ögonblicksbild. Miljön förändras varje dag – nya siter skapas, behörigheter justeras, SPFx-lösningar uppdateras. Pentestet ger er en solid baslinje, men den behöver kompletteras med:

• Kontinuerlig konfigurationsövervakning – automatiserad kontroll av delningsinställningar, samtycken och behörighetsändringar
• SharePoint-auditlogg-integration med SIEM/SOC – larm på avvikande mönster som massexport eller behörighetseskalering
• Regelbundna behörighetsgranskningar – kvartalsvis genomgång av vem som har åtkomst till känsliga siter
• Årligt pentest med fördjupning i nya funktioner och integrationer

Managerad DevOps

Det är den kombinationen – punkt-i-tiden-verifiering genom pentest plus kontinuerlig övervakning genom SOC – som faktiskt minskar risk på riktigt. Endera isolerat ger en falsk trygghet.

Vanliga frågor

Hur ofta bör man genomföra pentest av SharePoint?

Minst årligen, samt vid större förändringar som migrering till SharePoint Online, införande av nya SPFx-webparts eller förändrade behörighetsmodeller. NIS2-direktivet förutsätter regelbunden verifiering av säkerhetsåtgärder, vilket i praktiken innebär att årlig testning är ett minimum för organisationer som omfattas.

Kan man pentesta SharePoint Online utan Microsofts godkännande?

Ja, sedan 2017 tillåter Microsoft penetrationstestning mot den egna tenanten utan förhandsgodkännande, förutsatt att testerna följer Microsofts Rules of Engagement. Du behöver alltså inte öppna ett ärende – men du får inte testa andra tenanter eller gemensam infrastruktur.

Vad kostar ett pentest av SharePoint ungefär?

Priset varierar kraftigt beroende på scope – en fokuserad test av en enskild SharePoint-site med begränsad custom code kan kosta från cirka 50 000 SEK, medan en fullständig granskning av en komplex hybrid-miljö med on-prem och Online, SPFx-lösningar och tredjepartsintegrationer kan landa på 200 000–400 000 SEK.

Vad är skillnaden mellan sårbarhetsskanning och pentest av SharePoint?

En sårbarhetsskanning är automatiserad och hittar kända CVE:er och felkonfigurationer. Ett pentest går djupare: testaren försöker aktivt eskalera behörigheter, kedja ihop sårbarheter och simulera vad en verklig angripare skulle göra. Skanningen hittar dörren – pentestet visar vad som händer när någon går igenom den.

Behöver vi testa SharePoint om vi redan har Microsoft Defender for Office 365?

Ja. Defender skyddar mot kända hot och ger telemetri, men testar inte er specifika konfiguration, behörighetsmodell eller custom code. Pentest validerar att era säkerhetslager faktiskt fungerar som tänkt i just er miljö.