Independent. Dynamic. Involved.
nlen

Hoe krijg je grip op computer-gebaseerde privileged accounts?

Door Brian de Vries, technisch consultant bij Traxion.  Privileged accounts zijn de kroonjuwelen van een organisatie. Ze zijn in verschillende soorten te vinden. Het grootste onderscheid in de verschillende soorten privileged accounts is te maken op basis van het gebruik. Zo zijn er de privileged accounts die gebruikt worden door de beheerders en de privileged accounts die gebruikt worden door computersystemen. Een privileged account dat gebruikt wordt door een beheerder zal in de regel gemanaged of in ieder geval bekend moeten zijn. Een overzicht creëren en managen van de privileged accounts die gebruikt worden door computersystemen is uitdagender voor een organisatie.

In een eerdere blog heb ik aangegeven dat de implementatie van een oplossing voor Privileged Account Management (PAM) meer behelst dan een tool in gebruik nemen. Dat vraagt namelijk ook om cultuurverschuivingen. In deze blog ga ik dieper in op de vereiste cultuurverschuivingen om het beheren van privileged accounts die door computersystemen worden gebruikt mogelijk te maken.

Service, applicatie, hard-coded en robotic accounts

Er zijn verschillende typen privileged accounts die door computersystemen gebruikt kunnen worden. De meest bekende is een service account. Dit type account wordt bijvoorbeeld gebruikt om specifieke Windows-services te draaien. Denk aan een geplande taak die dagelijks automatisch uitgevoerd moet worden, of een service ten behoeve van een database of applicatie. Het kan ook gaan om services als het automatisch installeren van software-updates of andere software-agents.
Een ander type privileged account is een applicatie-account, welke binnen een applicatie wordt gebruikt om bijvoorbeeld een koppeling te maken met andere bedrijfsapplicaties of databases. Een voorbeeld hiervan is BizTalk of Orchestrator. In de interne logica van deze applicaties is het mogelijk om acties in andere applicaties of op een server te initiëren.
Nog een ander type, de hard-coded accounts, wordt voornamelijk gebruikt binnen scripts. Dit kunnen Windows Powershell-scripts zijn, C++-scripts of Java-scripts. Maar ook binnen bijvoorbeeld Windows Internet Information Services (IIS) zijn hard-coded credentials te gebruiken voor bijvoorbeeld application pools of IIS virtual directories.
Tenslotte is er een opmars van zogenaamde robotic accounts, door de snelgroeiende implementaties van RPA-toepassingen. De robotic accounts worden door de RPA-software gebruikt om te kunnen inloggen in de verschillende bedrijfsapplicaties die opgenomen zijn in de RPA-processen.

Principle of least privileges toepassen

Bij het installeren, ontwikkelen of implementeren van een nieuwe applicatie of script zullen er altijd nieuwe privileged accounts aangevraagd moeten worden. Veelal wordt er een privileged account aangevraagd met administratorrechten. Niet omdat dit altijd nodig is, maar omdat het gemakkelijk is. Mochten er problemen ontstaan, dan kan het in ieder geval niet aan de rechten liggen. In veel gevallen is het ook nog een privileged account met rechten op domeinniveau binnen de organisatie. Een domeinaccount is namelijk terug te vinden in Active Directory, wat het inzichtelijker maakt welke privileged accounts er binnen een organisatie zijn. Ook kan dat privileged account tijdens de implementatie voor meerdere doeleinden gebruikt worden. Het wordt dus niet enkel gebruikt voor een specifieke Windows-service, maar voor meerdere services of servers. Hetzelfde account kan daarbij ook als applicatie-account gebruikt worden om te kunnen integreren met een andere applicatie.

Hoe meer rechten een specifiek privileged accounts krijgt en op hoe meer plekken het account gebruikt wordt, des te interessanter het voor een aanvaller wordt om dat account te willen bemachtigen. Het is daarom van belang om bij het aanmaken en toekennen van privileged accounts goed vast te stellen waarvoor het account gebruikt gaat worden. Indien er enkel leesrechten nodig zijn voor een aantal specifieke lokale mappen, ken deze dan ook enkel toe aan een lokaal account. Moet er vanuit de applicatie nog een koppeling gemaakt worden naar een andere applicatie? Maak dan een extra account aan met die specifieke rechten. De juiste minimale rechten toekennen aan een account wordt de “principle of least privileges” genoemd. Het kunnen toepassen daarvan vraagt dus aan de aanvrager goed uit te zoeken welke rechten er nodig zijn. Aan de andere kant zal de uitgever van het privileged account kritisch moeten zijn bij aanvragen en de rechten juist toepassen.

Lateral movement voorkomen

In de praktijk zien we vaak dat serviceaccounts op domeinniveau zijn aangemaakt, waarbij er rechten zijn toegekend op meerdere servers. Op die servers zijn weer andere domeingerelateerde serviceaccounts gebruikt die rechten geven op een andere set servers. Dit biedt een mogelijke aanvaller de gelegenheid om lateraal te kunnen voortbewegen door de infrastructuur. Het gevolg kan zijn dat de volledige infrastructuur inclusief de domain controllers gecompromitteerd raken. En dat is in sommige gevallen al mogelijk op basis van drie verschillende privileged accounts.

Om de kans op lateral movement te verkleinen, is er een aantal mitigerende mogelijkheden. In het verlengde van de principle of least privileges heeft het de voorkeur om lokale privileged accounts met unieke wachtwoorden  te gebruiken, en zo min mogelijk domeingerelateerde privileged accounts. Als een lokaal privileged account gecompromitteerd is, kan deze niet gebruikt worden om op andere servers te komen.
Ook is het mogelijk om op netwerkniveau logische scheidingen aan te brengen. Dit is mogelijk door het gebruik van interne firewalls, het aanbrengen van netwerk(micro)segmentatie of het implementeren van het Microsoft Tier-model. Het doel van het aanbrengen van logische scheidingen is voorkomen dat kritische systemen makkelijk benaderbaar zijn vanaf minder kritische systemen. Voor het implementeren van een dergelijke mitigatie zullen enterprise-architecten, securityspecialisten en infrabeheerders heel nauw moeten samenwerken.

Regelmatige rotatie met complexe wachtwoorden

Als startpunt van een PAM-implementatie voeren wij vaak een scan uit die inzichtelijk maakt welke privileged accounts er binnen een organisatie bestaan.
Uit deze scan blijkt ook wanneer het wachtwoord van een privileged account voor het laatst gewijzigd is. Vooral bij de gevonden service accounts zien we vaak dat wachtwoorden al jaren niet gewijzigd zijn. De onderliggende reden hiervan is waarschijnlijk dat het onduidelijk is hoe en waar het serviceaccount gebruikt wordt. Als het wachtwoord gewijzigd wordt en er wordt een service vergeten mee te wijzigen, kan dit betekenen dat bedrijfskritische applicaties onbereikbaar worden. Een andere onderliggende reden kan zijn dat de eigenaar van een serviceaccount niet bekend is en er dus ook niet meer actief beheerd wordt.
Dit geldt ook voor de applicatie en hard-coded accounts; deze zijn vaak ooit aangemaakt en daarna nooit meer aangepast. In zekere zin kan dit tenslotte ook voor robotic accounts het geval zijn. Het moet de bedoeling zijn dat de maximale wachtwoordleeftijd voor een robotic account gelijk is aan die van een mens, maar vanuit het gemak kan deze restrictie opgeheven zijn.

De wachtwoorden van service accounts worden op de server in zogenaamde hashes opgeslagen. Met tools zoals Mimikatz is het mogelijk om de hashes terug te vertalen naar leesbare wachtwoorden. Wanneer het wachtwoord van een serviceaccount al jaren oud is, bestaat de kans dat de complexiteit van het wachtwoord zwak is. En hoe zwakker wachtwoorden zijn, des te makkelijker het is om deze leesbaar te krijgen. Doordat er ook geen regelmatige rotatie van de wachtwoorden (en dus van de hashes) plaatsvindt, zou een aanvaller voor lange tijd onopgemerkt misbruik van het serviceaccount kunnen maken. En voor de andere typen accounts is het misschien zelfs niet eens nodig om deze met tools leesbaar te maken, omdat ze al leesbaar opgeslagen zijn in applicaties, scripts of RPA-oplossingen.
Zodra de privileged accounts onder beheer van de PAM-oplossing geplaatst zijn, is het mogelijk om complexe wachtwoorden op regelmatige basis automatisch te genereren. Hierdoor wordt het moeilijker deze leesbaar te krijgen met tools zoals Mimikatz. Als een aanvaller er al in slaagt om het wachtwoord te achterhalen, kan deze slechts voor een beperkte tijd misbruikt worden. En voor de detectie van misbruik hebben de meeste PAM-oplossingen ook threatdetectie-modules beschikbaar.

Business-accounts of domain administrators niet voor services gebruiken

Helaas zien wij ook nog regelmatig dat de zogenaamde business-accounts gebruikt worden om services te draaien. Het betreft hier dan voornamelijk geplande taken op een Windows-service om dagelijks een handeling uit te voeren, zoals het veiligstellen van logbestanden. Een business-account dat voor dagelijks gebruik bedoeld is, om in te loggen op een werkplek, applicatie of om bijvoorbeeld mail te lezen, wordt hierdoor ineens een kroonjuweel.
Het gebruik van een business-account is gevaarlijk, omdat deze het makkelijkst door een aanvaller buit te maken is. Simpelweg door bijvoorbeeld te klikken op een link in een phishing-email kan een gebruiker zijn wachtwoord al compromitteren. De aanvaller kan dan vervolgens het wachtwoord misbruiken en inloggen op de server waarop een service draait onder dat business-account. Als er andere domeinserviceaccounts gebruikt worden op die server, kan de aanvaller daar de hash van pakken en zo lateraal verder bewegen.

Aan de andere kant zien we dat één van de belangrijkste soort kroonjuwelen ook gebruikt worden voor het draaien van services, de domain administrator accounts. Deze hebben privileges over de gehele infrastructuur. Als een aanvaller hiervan een hash of wachtwoord weet te bemachtigen, kan de gehele infrastructuur benaderd worden, en bijvoorbeeld een ransomware aanval worden uitgevoerd. Een service onder een domain administrator account vergroot de kansen op een Pass-the-Hash of Golden Ticket aanval.

De organisatie moet dus actief blijven monitoren onder welke accounts services draaien en of dit accounts zijn waarop de principle of least privileges is toegepast. Een organisatie moet zich er zeer bewust van zijn dat te veel rechten op een privileged account een groot risico met zich meebrengt met ondenkbare gevolgen.

PAM als initiator voor algehele IT-security verbeteringen

Enkel het implementeren van de PAM-oplossing is niet voldoende. Er moeten andere werkwijzen toegepast worden. Er moet strikter vastgesteld worden waarvoor een privileged account gebruikt moet worden, welke rechten er nodig zijn. Hoe hoger de rechten, hoe meer beveiligingsrisico er ontstaat. De volledige infrastructuur zal onder de loep genomen moeten worden om logische scheidingen aan te brengen binnen de infrastructuur. Wachtwoorden zullen regelmatig gewijzigd moeten worden. Een organisatie moet actief monitoren dat services niet onder persoonlijke business accounts of domain administrator accounts draaien. Het hogere doel van een organisatie moet zijn om de algehele IT-security te verbeteren waardoor aanvallers moeilijker systemen kunnen compromitteren. PAM kan de initiator van dit hogere doel zijn en het management op uw kroonjuwelen van u overnemen.

Wilt u meer weten over een PAM-oplossing voor uw organisatie? Traxion denkt graag met u mee. Maak een afspraak om te bespreken wat de mogelijkheden voor u zijn.

Dit artikel is ook geplaatst op https://www.infosecuritymagazine.nl/blogs/hoe-krijg-je-grip-op-computer-gebaseerde-privileged-accounts