🥇Gebruik PowerShell voor het verhogen van de privileges van lokale accounts

Privilege escalation is the exploitation of a current account's rights by a malicious actor to gain additional, usually higher-level access within a system. Although privilege escalation can result from the exploitation of zero-day vulnerabilities, or the actions of elite hackers conducting targeted attacks, or carefully disguised malware, it is more often a result of misconfigured computers or accounts. As the attack develops, attackers leverage a series of individual vulnerabilities, which can collectively lead to catastrophic data breaches.

Waarom gebruikers geen lokale administratorrechten zouden moeten hebben?

Als je een beveiligingsspecialist bent, lijkt het misschien voor de hand liggend dat gebruikers geen lokale administratorrechten zouden moeten hebben, omdat dit:

Hun accounts kwetsbaarder maakt voor verschillende aanvallen
Deze aanvallen veel ernstiger maakt

Helaas blijft dit voor veel organisaties een zeer controversieel onderwerp, vaak vergezeld van felle discussies (zie bijvoorbeeld, mijn leidinggevende zegt dat alle gebruikers lokale administrators moeten zijn). Zonder in detail op deze discussie in te gaan, geloven we dat de aanvaller lokale administratorrechten heeft verkregen op het onderzochte systeem: hetzij via een exploit, hetzij omdat de machines niet adequaat waren beveiligd.

Stap 1. Terugkerende DNS-resolutie via PowerShell

Standaard is PowerShell geïnstalleerd op veel lokale werkstations en op de meeste Windows-servers. En hoewel het zonder overdrijving wordt beschouwd als een ongelooflijk nuttig hulpmiddel voor automatisering en beheer, kan het evenzeer veranderen in bijna onzichtbare fileless malware (een hackprogramma dat geen sporen van de aanval achterlaat).

In ons geval begint de aanvaller met netwerkkundig onderzoek via een PowerShell-script, waarbij hij systematisch het IP-adresruimte van het netwerk doorloopt, probeert te achterhalen of het opgegeven IP naar een knooppunt wordt geresolviseerd, en zo ja, wat de netwerknaam van dat knooppunt is.
Er zijn veel manieren om deze taak uit te voeren, maar het gebruik van de cmdlet Get-ADComputer is een betrouwbare optie, omdat het echt een rijke set gegevens over elk knooppunt teruggeeft:

 import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq ‘10.10.10.10’}

Als de snelheid in grote netwerken problemen veroorzaakt, kan een omgekeerde DNS-systemaanroep worden gebruikt:

[System.Net.Dns]::GetHostEntry(‘10.10.10.10’).HostName

Deze methode voor het opsommen van knooppunten in het netwerk is erg populair, omdat de meeste netwerken geen zero trust-beveiligingsmodel gebruiken en interne DNS-aanvragen voor verdachte pieken in activiteit niet volgen.

Stap 2: Selecteren van het doel

Het eindresultaat van deze stap is het verkrijgen van een lijst van hostnamen van servers en werkstations, die kan worden gebruikt om de aanval voort te zetten.

Aan de naam te zien lijkt de server ‘HUB-FILER’ een waardig doel, aangezien bestandsservers na verloop van tijd doorgaans een groot aantal netwerkmappen en overmatige toegang door een breed scala aan mensen accumuleren.

Kijkend met de Windows Verkenner kunnen we bepalen of er een open gedeelde map is, maar onze huidige account heeft er geen toegang toe (waarschijnlijk hebben we alleen rechten om te lijst te maken).

Stap 3: Onderzoek naar ACL

Nu kunnen we op onze host HUB-FILER en de doel-shared map share een PowerShell-script uitvoeren om de lijst van ACL te verkrijgen. Dit kunnen we vanuit de lokale machine doen, omdat we al lokale beheerdersrechten hebben:

(get-acl hub-filershare).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –auto

Uitvoerresultaat:

Hieruit blijkt dat de groep Domeingebruikers alleen toegang heeft tot lijstweergave, terwijl de groep Helpdesk ook wijzigingsrechten heeft.

Stap 4: Identificatie van Accountaccounts

Door Get-ADGroupMember, kunnen we alle leden van deze groep verkrijgen:

Get-ADGroupMember -identity Helpdesk

In deze lijst zien we het computeraccount dat we al hebben geïdentificeerd en waar we al toegang toe hebben gekregen:

Stap 5: Gebruik PSExec voor werking vanuit het computeraccount

PsExec van Microsoft Sysinternals stelt ons in staat om commando's uit te voeren in de context van het systeemaccount SYSTEM@HUB-SHAREPOINT, dat, zoals we weten, lid is van de doelgroep Helpdesk. Dus hoeven we alleen maar uit te voeren:

PsExec.exe -s -i cmd.exe

Daarna heeft u volledige toegang tot de doelfolder HUB-FILERshareHR, aangezien u werkt binnen de context van het computeraccount HUB-SHAREPOINT. Met deze toegang kunnen gegevens worden gekopieerd naar een draagbaar opslagapparaat of op andere manieren worden opgehaald en via het netwerk worden overgedragen.

Stap 6: Detectie van deze aanval

Deze specifieke kwetsbaarheid in de configuratie van de toegangsrechten van accounts (computeraccounts die toegang hebben tot gedeelde netwerk mappen in plaats van gebruikers- of serviceaccounts) kan worden gedetecteerd. Maar zonder de juiste hulpmiddelen is dit zeer moeilijk.

Om deze categorie aanvallen te detecteren en te voorkomen, kunnen we gebruikmaken van DatAdvantage om groepen met computeraccounts te identificeren en vervolgens de toegang ertoe te blokkeren. DatAlert gaat verder en stelt ons in staat om een melding te maken speciaal voor zo'n scenario.

In de onderstaande screenshot ziet u een gebruikersmelding die wordt geactiveerd bij elke toegang van een computeraccount tot gegevens op de bewaakte server.