Pentest av on-prem Active Directory

Rekognosering och kartläggning

Första steget i ett AD-pentest är att förstå miljöns topologi. Med verktyg som BloodHound och SharpHound kartlägger testaren relationer mellan användare, grupper, datorer och GPO:er. Resultatet är en graf som visar potentiella attackvägar – exempelvis att en helpdesk-tekniker som kan logga in på en arbetsstation där en domänadmin har en cachad session.

Specifikt letar vi efter:

• Kerberoastable-konton – tjänstekonton med SPN som använder svaga lösenord. En Kerberos TGS-biljett kan begäras av vilken autentiserad användare som helst och sedan krackas offline.
• AS-REP roastable-konton – konton utan Kerberos pre-authentication, vilket tillåter offlineattacker utan ens en giltig session.
• Unconstrained delegation – servrar som får agera som vilken användare som helst mot vilken tjänst som helst. En komprometterad sådan server ger i praktiken domänadmin.
• GPO-svagheter – felkonfigurerade gruppolicyer som tillåter privilegieeskalering, exempelvis genom att en icke-admin kan redigera en GPO som appliceras på domänkontrollanter.

Vanliga attackvägar vi ser i produktion

Baserat på uppdrag Opsios team genomfört de senaste två åren ser vi återkommande mönster:

Den vanligaste attackkedjan vi ser: en testare börjar med ett vanligt användarkonto, hittar ett Kerberoastable tjänstekonto, krackar dess lösenord, använder det kontots behörigheter för att nå en server med unconstrained delegation, och fångar sedan en domänadmins TGT. Hela kedjan tar ofta under en arbetsdag.

Verktyg i praktiken

• BloodHound/SharpHound – grafbaserad analys av AD-relationer
• Impacket – Python-bibliotek för nätverksprotokoll (Kerberos, SMB, LDAP)
• Rubeus – Kerberos-attacker (kerberoasting, delegation-abuse)
• CrackMapExec – automatiserad lateral förflyttning och credential-validering
• PurpleKnight/Pingcastle – automatiserad AD-säkerhetsbedömning (bra som bas, ersätter inte manuellt test)

Pentest av Entra ID

Annorlunda attackyta, annorlunda metodik

Entra ID är inte bara "AD i molnet" – det är en fundamentalt annorlunda arkitektur. Här finns inga domänkontrollanter att attackera, ingen NTLM att reläa, och inget filsystem att traversera. Istället handlar det om API:er, OAuth 2.0-flöden, och JSON Web Tokens.

Testningen fokuserar på:

• App-registreringar och service principals – överdimensionerade API-behörigheter (exempelvis Directory.ReadWrite.All eller Mail.ReadWrite för en app som bara behöver läsa profiler)
• Villkorsstyrd åtkomst (Conditional Access) – luckor i policyer som tillåter inloggning utan MFA från vissa enheter, platser eller klienter
• Gästanvändare och B2B-federation – extern åtkomst som inte begränsats korrekt
• Token-hantering – för långa token-livstider, avsaknad av Continuous Access Evaluation (CAE)
• Privileged Identity Management (PIM) – rollaktiveringar utan tillräcklig motivering eller godkännande

Vanliga fynd i Entra ID

I Opsios erfarenhet är dessa de mest frekvent förekommande problemen:

Överprivilegierade app-registreringar står ut som det enskilt vanligaste fyndet. Utvecklare begär breda behörigheter under utveckling och tar aldrig bort dem. En komprometterad app med Directory.ReadWrite.All ger i praktiken global administratörsåtkomst.

Villkorsstyrd åtkomst med luckor är näst vanligast. En policy som kräver MFA för "alla molnappar" men som exkluderar legacy-autentisering, eller som inte täcker Azure CLI och PowerShell, skapar en bakdörr som angripare aktivt utnyttjar.

Consent-attacker – en angripare registrerar en extern app som begär behörigheter, och en användare godkänner utan att förstå konsekvenserna. Om admin consent-policyer inte är restriktiva kan en enda användares klick ge angriparen bred åtkomst.

Verktyg för Entra ID-testning

• ROADtools – kartläggning av Entra ID-miljön via Graph API
• AADInternals – PowerShell-toolkit för Entra ID-attacker och rekognosering
• TokenTactics – manipulation och analys av OAuth-tokens
• Catapult/GraphRunner – automatiserad enumeration av Graph API-behörigheter
• Az CLI / Az PowerShell – manuell testning av Azure-resurser och rolltilldelningar

Hybridmiljöer – den kritiska blinda fläcken

De flesta svenska organisationer befinner sig i en hybridkonfiguration: on-prem AD synkroniserat med Entra ID via Azure AD Connect. Det skapar attackvägar som överskrider gränsen mellan on-prem och moln.

Azure AD Connect som attackvektor

Azure AD Connect-servern har ett tjänstekonto med replikeringsrättigheter i AD (DCSync-behörighet) och ett konto med privilegier i Entra ID. En angripare som komprometterar denna server kan:

1. Extrahera lösenordshashar för alla synkroniserade konton via DCSync

2. Använda molnkontots behörigheter för att eskalera i Entra ID

3. Modifiera synkroniseringsregler för att injicera behörigheter

Vår rekommendation: Azure AD Connect-servern ska behandlas med samma skyddsnivå som en domänkontrollant. Tiered access-modell, dedicerad server, begränsad nätverksåtkomst, och övervakning via SOC.

Pass-the-Hash och Pass-the-PRT

I hybridmiljöer kan en on-prem-kompromiss leda till stöld av Primary Refresh Tokens (PRT) – den token som ger SSO-åtkomst till molnresurser. En angripare med en giltig PRT kan kringgå villkorsstyrd åtkomst som litar på "compliant device" eller "Hybrid Azure AD Joined".

Managerade molntjänster

Metodik för ett strukturerat pentest

Scope och avgränsning

Innan testet påbörjas behöver scope definieras tydligt:

Fasindelning

Fas 1: Rekognosering (1–2 dagar)

Kartläggning av miljön utan aktiva attacker. OSINT, DNS-enumeration, identifiering av hybridkonfiguration. I Entra ID: enumeration av domännamn, federation-konfiguration, tenant-information via offentliga endpoints.

Fas 2: Sårbarhetsbedömning (2–3 dagar)

Aktiv testning av identifierade attackytor. Kerberoasting, ASREPRoast, BloodHound-analys, token-granskning, policygranskning.

Fas 3: Exploitation (2–5 dagar)

Verifiering av sårbarheter genom kontrollerad exploatering. Privilegieeskalering, lateral förflyttning, datåtkomst.

Fas 4: Rapportering och åtgärdsplan (2–3 dagar)

Detaljerad rapport med riskklassificering, reproduktionssteg och prioriterade åtgärder. Executive summary för ledning, teknisk detalj för IT-team.

Åtgärder som faktiskt fungerar

Baserat på hundratals uppdrag har vi destillerat de åtgärder som ger störst effekt:

On-prem AD

1. Eliminera Kerberoastable-konton – byt till group Managed Service Accounts (gMSA) med 120+ tecken automatiskt roterade lösenord

2. Aktivera SMB-signering på alla system – stoppar NTLM-reläattacker

3. Implementera tiered access – separera administratörskonton för arbetsstation, server och domän

4. Begränsa unconstrained delegation – migrera till constrained eller resource-based constrained delegation

5. Övervaka DCSync-anrop – alla replikeringsanrop som inte kommer från kända domänkontrollanter ska trigga larm

Entra ID

1. Granska alla app-registreringars behörigheter – tillämpa principen om minsta behörighet

2. Stäng legacy-autentisering – blockera via villkorsstyrd åtkomst, inte bara genom att inaktivera protokoll

3. Kräv admin consent för alla app-behörigheter – eliminera consent-attacker

4. Implementera Continuous Access Evaluation (CAE) – tokens revokeras i nära realtid vid riskförändringar

5. Aktivera PIM med tidsbegränsade roller – ingen permanent global admin

Managerad DevOps

NIS2 och regulatoriska krav

NIS2-direktivet, som ska vara implementerat i svensk lagstiftning, ställer explicita krav på att organisationer i väsentliga och viktiga sektorer genomför regelbunden riskanalys och säkerhetstestning. Penetrationstest av identitetstjänster adresserar direkt flera av direktivets kärnkrav:

• Artikel 21(2)(a) – riskanalys och säkerhetspolicyer för informationssystem
• Artikel 21(2)(e) – säkerhet vid anskaffning, utveckling och underhåll av system, inklusive hantering av sårbarheter

GDPR ställer också indirekt krav genom artikel 32 (lämpliga tekniska och organisatoriska åtgärder) – och IMY har i tillsynsbeslut refererat till brister i identitetshantering som grund för sanktionsavgifter.

För organisationer som omfattas av SOC 2 eller ISO/IEC 27001 är penetrationstestning en förväntad kontroll under respektive ramverks kravområden för sårbarhetshantering.

Cloud FinOps

Opsios perspektiv: vad vårt SOC ser i realtid

Från vårt SOC/NOC i Karlstad och Bangalore ser vi dagligen attacker mot identitetstjänster. De tre vanligaste attackmönstren just nu:

1. Lösenordssprejning mot Entra ID – angripare testar ett fåtal vanliga lösenord mot många konton för att undvika lockout. Villkorsstyrd åtkomst som blockerar legacy-auth och kräver MFA stoppar detta effektivt.

2. Token-stöld via AiTM-phishing – adversary-in-the-middle-attacker som fångar sessionstoken trots MFA. CAE och token binding är de viktigaste motåtgärderna.

3. Lateral förflyttning via on-prem till moln – angripare komprometterar en on-prem-server, stjäl en PRT, och använder den för att komma åt SharePoint, Teams och Azure-resurser. Tiered access och PRT-skydd är avgörande.

Penetrationstester som simulerar dessa scenarier ger er ett kvantifierbart mått på hur väl era försvar fungerar – inte i teorin, utan mot de attacker som faktiskt pågår.

Molnmigrering

Vanliga frågor

Vad är skillnaden mellan pentest av AD och Entra ID?

On-prem AD-test fokuserar på Kerberos-attacker, NTLM-reläer och GPO-svagheter. Entra ID-test riktar in sig på OAuth/OIDC-konfigurationer, villkorsstyrd åtkomst, app-registreringar och API-behörigheter. I hybridmiljöer behöver ni testa båda – inklusive synkkontot i Azure AD Connect som ofta har för vida rättigheter.

Hur ofta bör vi genomföra penetrationstest av identitetstjänster?

Minst årligen för att uppfylla NIS2 och de flesta ramverk. Därutöver vid större förändringar: migrering till Entra ID, ny federation, nya villkorsstyrda policyer eller efter en incident. Opsios rekommendation är kvartalsvis automatiserad scanning kompletterad med manuellt pentest en till två gånger per år.

Påverkar ett pentest driften i produktionsmiljön?

Med rätt avgränsning och kommunikation är risken minimal. Tester av AD görs normalt med kontrollerade konton och begränsade scope. Lösenordssprejning mot Entra ID kräver exempelvis att man respekterar lockout-policyer. Opsios SOC övervakar testerna i realtid så att eventuella driftpåverkande aktiviteter kan stoppas omedelbart.

Räcker det med automatiserade verktyg för att testa AD-säkerheten?

Nej. Verktyg som BloodHound och PurpleKnight identifierar kända felkonfigurationer, men en erfaren testare hittar kontextberoende sårbarheter – som en tjänstekontoskedja som ger domänadmin via tre hopp. Automatisering är en utmärkt bas, men manuell testning behövs för att simulera verkliga angripare.

Hur relaterar pentest till NIS2-direktivet?

NIS2 kräver att organisationer i väsentliga och viktiga sektorer genomför regelbunden riskanalys och säkerhetstestning. Penetrationstest av identitetstjänster är ett direkt sätt att uppfylla kravet på teknisk sårbarhetshantering. Resultaten fungerar också som dokumentation vid tillsyn från MSB.