Hoe Entra ID dynamische groepen te misbruiken
Dynamische groepen in Entra ID maken toegangsbeheer makkelijk. Maar een simpele configuratiefout kan een aanvaller ongemerkt admin-rechten geven. In deze blog laat ik zien hoe deze aanval werkt, en belangrijker nog, hoe je hem voorkomt.
Dynamische groepen in Microsoft Entra ID zijn een handige functie voor automatisch toegangsbeheer. Maar wat als een aanvaller deze functionaliteit tegen je gebruikt? In deze blog laat ik zien hoe een simpele configuratiefout kan leiden tot ongeautoriseerde beheertoegang, en belangrijker nog, hoe je dit voorkomt.
Binnen Microsoft Entra ID kun je op verschillende manieren toegang geven tot applicaties, resources en taken. Door gebruik te maken van Entra groepen kun je rechten uitdelen op basis van deze groepen, in plaats van individuele gebruikers. Dit maakt het beheer van de omgeving overzichtelijker en makkelijker, wat ten goede komt van de veiligheid van de Entra ID omgeving.
In Entra ID heb je twee typen groepen: Microsoft 365 groepen en Security groepen. Microsoft 365 groepen worden gebruikt om 365 resources te koppelen, zoals Teams kanalen en gedeelde mailboxen. Security groepen worden gebruikt om rechten binnen de Azure omgeving uit te delen.
In dit geval gaan we gebruik maken van security groepen, om rechten binnen een Azure omgeving te verkrijgen en verhogen. Er zijn drie typen security groepen: Statisch assigned, waarbij deze leden van een groep handmatig door een beheerder worden toegevoegd en twee dynamische groepen, één voor gebruikers en één voor apparaten. Leden van deze dynamische groepen worden niet handmatig toegevoegd, maar worden toegevoegd op basis van een ingestelde regel. Dergelijke typen groepen kunnen handig zijn voor bijvoorbeeld toevoegen van rechten, op basis van je locatie, afdeling, functie, enzovoorts.
In dit voorbeeld maken we gebruik van een dynamische admin groep, die automatisch beheerdersaccounts toevoegt aan deze. Dit kan worden gebruikt in dynamische omgevingen, waarin geregeld nieuwe beheerdersaccounts worden aangemaakt en verwijderd.
Om dynamische security groepen te gebruiken binnen je Azure omgeving heb je minimaal de Entra ID P1 licentie nodig.
Een dynamische groep kan worden aangemaakt vanuit de entra.microsoft.com portal. Kies Entra ID -> Groups -> All groups – New group
Je hebt de keuze uit groep type Security en Microsoft 365. Microsoft 365 wordt gebruikt om 365 resources aan te koppelen, zoals Teams kanalen en gedeelde mailboxen. Security groepen is voor rechten binnen de Azure omgeving, wat we in dit voorbeeld nodig hebben.
We selecteren hier security groep. Geef een gepaste naam en beschrijving op en kies als membership type Dynamic User
Door vervolgens op Add dynamic query te klikken kun je de regel(s) opgeven waaraan een useraccount moet voldoen om aan deze groep te worden toegevoegd.
In deze demo omgeving maken we gebruik van beheerdersaccounts. Deze accounts zijn te herkennen aan een UPN beginnend met 'adm'. In veel organisaties is het gebruikelijk om beheerdersaccounts te herkennen aan voorvoegsels zoals 'adm', 'admin' of achtervoegsels zoals '-admin'.
Sla deze regel op en kies vervolgens create
Vanaf dit moment heb je een Azure groep, waaraan je specifieke beheerrechten kunt koppelen of kunt koppelen aan Azure applicaties.
In een Entra ID omgeving zitten altijd gebruikersaccounts. In deze demo omgeving heb ik er verschillende. Het account dat ik hier gebruik is een reguliere gebruiker, met wat user rechten binnen de Azure en Microsoft365 omgeving. Geen van deze rechten heeft enige vorm van beheertoegang.
Tot zover de voorbereiding van de demo omgeving. Nu gaan we kijken hoe we, als kwaadwillende, binnen deze omgeving kunnen komen.
Een eerste stap is om een guest account binnen de Azure omgeving te kunnen krijgen. Een Entra ID guest account is een extern gebruikersaccount dat toegang krijgt tot bepaalde resources binnen jouw Azure- of Microsoft 365-tenant, zonder dat die persoon een interne medewerker is. Dergelijke accounts worden gebruikt om samen te werken met externe partners, om deze toegang te geven tot SharePoint sites, Teams kanalen of specifieke applicaties
We maken hierbij gebruik van een tool genaamd Graphrunner. Deze toolset is ontwikkeld door Black Hills Information Security (https://www.blackhillsinfosec.com/introducing-graphrunner) en is gebaseerd op PowerShell en maakt gebruik van de Microsoft Graph API om met de Entra ID te verbinden.
Deze PowerShell modules heb ik geïmporteerd op mijn "hacker machine". Dit kan zowel een Windows of een Linux device zijn, zolang het maar beschikt over PowerShell.
Door List-GraphRunnerModules in te geven krijg je een overzicht van alle mogelijkheden van deze tool.
Vanuit de PowerShell modules starten we met Get-GraphTokens. Dit geeft je de URL naar de Microsoft device inlogpagina en bijbehorende registratiecode.
Een gebruiker die zich niet bewust is van de gevaren van cybersecurity is een van de grootste gevaren binnen een corporate IT-infrastructuur. Kwaadwillenden maken veelvuldig gebruik van informatie, welke openlijk op social media wordt gepost. Via een platform als LinkedIn weet een kwaadwillende namen van IT-servicedesk medewerkers te bemachtigen. Door zich voor te doen als een van deze medewerkers, en gebruik te maken van een gespooft mailadres of telefoonnummer, kan hij een gebruiker overhalen zich aan te melden binnen de legitieme Azure omgeving via de website https://microsoft.com/devicelogin en vervolgens een token code te laten opgeven. Dit is een legitieme Microsoft website. Na het invoeren van de code zal de gebruikersnaam en wachtwoord (en eventuele MFA verificatie) worden gevraagd.
Direct nadat de gebruiker zich heeft aangemeld heeft de Graphrunner tool de access and refresh tokens weten te bemachtigen. Deze tokens kunnen vervolgens worden gebruikt om, als de betreffende gebruiker, aan te melden binnen de Microsoft omgeving.
Als kwaadwillende willen we hierbij inzicht krijgen in het gebruik van groepen in deze Azure omgeving. In de lijst van modules van Graphrunner is hiervoor een commando:
Get-SecurityGroups
Om hierbij gebruik te maken van het, zojuist verkregen, token is het volledige commando als volgt:
Get-SecurityGroups -Tokens $tokens
Nu hebben we inzicht in alle groepen, die beschikbaar zijn in de omgeving. We willen in dit geval echter weten of er gebruik gemaakt wordt van dynamische groepen, die we mogelijk zouden kunnen misbruiken.
Dit kunnen we te weten komen door het commando:
Get-DynamicGroups -Tokens $token
En daar is de dynamische groep "All administrators". Ook kun je zien bij MembershipRule aan welke eisen je moet voldoen om lid van deze groep te worden.
We weten nu dat alle accounts, in de betreffende Entra ID omgeving, waarvan de User Principal Name begint met adm automatisch worden toegewezen aan de groep "All administrators"
Op dit moment maken we nog steeds gebruik van het token van de standaard gebruiker. Een standaard gebruiker is niet in staat om gebruikersaccounts aan te maken binnen een Entra ID omgeving. Wat een standaard gebruiker wel mag doen in een Entra ID omgeving is externe guest accounts uitnodigen. Deze optie staat default aan. Een externe guest account kan elk willekeurig mailadres zijn.
We weten dat elke account, beginnend met adm, automatisch wordt toegevoegd aan de "All administrators" groep. We kunnen nu een mailaccount aanmaken dat aan deze eis voldoet.
Een mailaccount aanmaken kan op meerdere manieren. Ik kies hier voor een Protonmail account. Maar je kunt elke andere provider gebruiken.
Als mailadres kies je een mailadres, startend met adm.
Nu we een mailadres hebben kunnen we deze uitnodigen als guest binnen de Azure omgeving door middel van het commando:
Invoke-InviteGuest -Tokens $tokens
Vul bij het invite mail address het zojuist aangemaakte mailadres in. De display naam die je opgeeft is de naam zoals deze zichtbaar wordt binnen Entra ID. Ik kies in dit geval Suspicious user maar in praktijk zal je hier een minder opvallende display naam kiezen. Een redirect URI is niet nodig, laat deze leeg. Send an email invitation – true Je kunt nog een custom message body ingeven, maar dat is hier niet nodig en kan worden leeggelaten.
Op dit moment komt er een nieuwe mail binnen van Microsoft op het aangemaakte mailaccount. Kies Accept invitation.
Er wordt een code verstuurd naar het mailadres. Vul de ontvangen code in en Sign in.
Vanaf dit moment hebben we een guest account binnen de Azure omgeving. En omdat onze guest user voldoet aan de voorwaarde lid te worden van de dynamische "All administrators" groep is deze ook automatisch lid geworden van deze groep.
In dit voorbeeld hebben we nu gebruik gemaakt van een groep die wordt gebruikt voor beheerrechten. Op deze zelfde manier zou je ook een account kunnen toevoegen aan dynamische groepen op basis van afdeling of functie. Door, in je gebruikersprofiel, je afdeling aan te passen naar "finance", zou dat guest account mogelijk toegang krijgen tot bijvoorbeeld gevoelige afdelingsdata, binnen de afdeling gedeelde mailboxen, specifieke applicaties of financiële informatie. Het naar buiten brengen van dergelijke informatie kan een grote impact hebben op de organisatie, in de vorm van financiële schade (kosten van herstel, boetes vanuit Autoriteit Persoonsgegevens) en reputatieschade.
In geval van een multinational zou je een dynamische groep kunnen hebben die je inloglocatie gebruikt, om rechten uit te delen voor de office locatie van dat betreffende land. De inloglocatie is hierbij makkelijk te vervalsen, door gebruik te maken van een VPN-verbinding.
Wat kunnen we verbeteren in Entra ID om te voorkomen dat kwaadwillenden misbruik maken van deze functie?
- Train je gebruikers op beveiligingsbewustzijn. Het is van essentieel belang dat gebruikers tijdig phishing en social engineering herkennen. Zorg voor een gedegen bewustwordingscampagne en dat dit een standaard onderdeel wordt van een arbeidsovereenkomst.
- Binnen je tenant kunnen een aantal standaard instellingen worden aangepast, waardoor de rechten voor gewone gebruikers worden beperkt:
Vanuit de Entra ID portal ga naar User settings
Zet User can create security groups naar No
Bij guest user access restrictions kies de most restrictive optie
Bij External collaboration settings kunnen ook een aantal van de default instellingen worden aangepast
Guest user restrictions dient te worden aangepast naar de most restrictive optie
Bij de guest invite settings is het afhankelijk van de wensen van de organisatie. Standaard staat ingesteld dat iedereen binnen de organisatie gastuitnodigingen kan versturen. Dit is niet wenselijk. Beter is het dit te beperken naar specifieke beheerderrollen.
- Naast het beperken van de mogelijkheid tot aanmaken van guest accounts kun je ook extra beleid afdwingen door gebruik te maken van een Conditional Access policy.
Je kunt hierbij token protection afdwingen. Wanneer een gebruiker een device registreert bij Microsoft Entra, dan wordt een Primary Refresh Token aan het device gekoppeld. Deze koppeling zorgt ervoor dat zelfs als een kwaadwillende actor een token steelt, deze niet vanaf een ander apparaat kan worden gebruikt. Om deze feature te kunnen gebruiken heb je een Microsoft Entra ID P1 licentie nodig.
Het is belangrijk een goed beeld te hebben van wat er allemaal in een Azure omgeving gebeurt. Het beschikbaar hebben van logging is hierbij essentieel. Deze logs kunnen als input dienen voor een Security Information and Event Management (SIEM) platform, die vervolgens een waarschuwing kan genereren, zodra een groepslidmaatschap van een beheergroep wordt aangepast.
In het voorbeeld van hierboven, maakt de kwaadwillende gebruik van een verkregen token, om vanaf een andere locatie als gebruiker in te loggen. Entra ID zal dit zien als risky sign-in. Ook hieraan kunnen alerts en geautomatiseerde mitigerende acties worden gekoppeld vanuit het SIEM platform.
In security assessments komen we regelmatig Azure omgevingen tegen, die voor een groot deel zijn gebaseerd op de default Microsoft instellingen. Terwijl dit niet de meest veilige instellingen zijn. Vaak is dit niet een bewuste keuze, maar is dit een gevolg van te weinig focus op security vanuit de organisatie of een gebrek aan specialistische kennis.
De eerste stappen die je zelf kunt zetten is het goed inzichtelijk hebben van de gebruikte gastaccounts, binnen je Entra ID omgeving: zijn deze accounts nog actief in gebruik, welke rechten hebben deze accounts, zijn deze gastaccounts gekoppeld aan verdachte mailadressen. Daarnaast kun je de mogelijkheden beperken voor het uitnodigen van nieuwe gastaccounts, zoals hierboven beschreven.
Conclusie
De belangrijkste beschermingsmaatregelen zijn:
- Structurele training van medewerkers in het herkennen van phishing
- Beperken van standaard gebruikersrechten (vooral het aanmaken van groepen en uitnodigen van gasten)
- Zorgvuldig ontwerpen van dynamische groepsregels met specifieke, moeilijk te voorspellen criteria
- Regelmatige audits van gastaccounts en groepslidmaatschappen
Wil je weten of jouw Azure-omgeving kwetsbaar is voor dit type aanval? Neem contact op voor een security assessment.