Privilege-escalatie is het gebruik door een aanvaller van de huidige rechten van een account om extra, meestal een hoger niveau, toegang tot het systeem te krijgen. Hoewel privilege-escalatie het resultaat kan zijn van het misbruiken van zero-day-kwetsbaarheden, of het werk van eersteklas hackers die een gerichte aanval uitvoeren, of slim vermomde malware, is dit meestal te wijten aan een verkeerde configuratie van de computer of het account. Bij het verder ontwikkelen van de aanval maken aanvallers gebruik van een aantal individuele kwetsbaarheden, die samen kunnen leiden tot een catastrofaal datalek.
Waarom mogen gebruikers geen lokale beheerdersrechten hebben?
Als u een beveiligingsprofessional bent, lijkt het misschien voor de hand liggend dat gebruikers geen lokale beheerdersrechten zouden moeten hebben, aangezien dit:
- Maakt hun accounts kwetsbaarder voor verschillende aanvallen
- Maakt diezelfde aanvallen veel ernstiger
Helaas is dit voor veel organisaties nog steeds een zeer controversieel onderwerp en gaat het soms gepaard met verhitte discussies (zie bijvoorbeeld ). Zonder op de details van deze discussie in te gaan, denken we dat de aanvaller lokale beheerdersrechten op het onderzochte systeem heeft verkregen, hetzij door een exploit, hetzij omdat de machines niet goed waren beschermd.
Stap 1Omgekeerde DNS-resolutie met PowerShell
PowerShell wordt standaard op veel lokale werkstations en op de meeste Windows-servers geïnstalleerd. En hoewel het niet zonder overdrijving wordt beschouwd als een ongelooflijk nuttig hulpmiddel voor automatisering en controle, is het ook in staat om zichzelf te transformeren in een bijna onzichtbaar (een hackprogramma dat geen sporen van de aanval achterlaat).
In ons geval begint de aanvaller netwerkverkenning uit te voeren met behulp van een PowerShell-script, waarbij hij achtereenvolgens de IP-adresruimte van het netwerk doorloopt en probeert vast te stellen of een bepaald IP-adres wordt omgezet naar een host, en zo ja, wat de netwerknaam van deze host is.
Er zijn veel manieren om deze taak uit te voeren, maar met behulp van de cmdlet ADComputer is een solide optie omdat het een heel rijke set gegevens over elk knooppunt retourneert:
import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq ‘10.10.10.10’}Als snelheid op grote netwerken een probleem is, kan een DNS-callback worden gebruikt:
[System.Net.Dns]::GetHostEntry(‘10.10.10.10’).HostName
Deze methode om hosts op een netwerk te vermelden is erg populair, aangezien de meeste netwerken geen zero-trust-beveiligingsmodel gebruiken en interne DNS-verzoeken niet controleren op verdachte uitbarstingen van activiteit.
Stap 2: Kies een doel
Het eindresultaat van deze stap is het verkrijgen van een lijst met server- en werkstationhostnamen die kunnen worden gebruikt om de aanval voort te zetten.
Gezien de naam lijkt de 'HUB-FILER'-server sindsdien een waardig doelwit na verloop van tijd verzamelen bestandsservers in de regel een groot aantal netwerkmappen en overmatige toegang daartoe door te veel mensen.
Door te browsen met Windows Verkenner kunnen we de aanwezigheid van een open gedeelde map detecteren, maar ons huidige account heeft er geen toegang toe (waarschijnlijk hebben we alleen vermeldingsrechten).
Stap 3: leer ACL's
Nu kunnen we op onze HUB-FILER-host en -doelshare een PowerShell-script uitvoeren om de ACL op te halen. We kunnen dit vanaf de lokale computer doen, aangezien we al lokale beheerdersrechten hebben:
(get-acl hub-filershare).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –autoUitvoering resultaat:
Hieruit zien we dat de groep Domeingebruikers alleen toegang heeft tot de lijst, maar dat de Helpdesk-groep ook wijzigingsrechten heeft.
Stap 4: Accountidentificatie
Rennen , kunnen we alle leden van deze groep krijgen:
Get-ADGroupMember -identity Helpdesk
In deze lijst zien we een computeraccount dat we al hebben geïdentificeerd en waar we al toegang toe hebben:
Stap 5: Gebruik PSExec om uit te voeren als een computeraccount
van Microsoft Sysinternals kunt u opdrachten uitvoeren in de context van het systeemaccount SYSTEM@HUB-SHAREPOINT, waarvan we weten dat het lid is van de Helpdesk-doelgroep. Dat wil zeggen, we hoeven alleen maar het volgende te doen:
PsExec.exe -s -i cmd.exeNou, dan heb je volledige toegang tot de doelmap HUB-FILERshareHR, aangezien je werkt in de context van het HUB-SHAREPOINT computeraccount. En met deze toegang kunnen de gegevens worden gekopieerd naar een draagbaar opslagapparaat of op een andere manier worden opgehaald en verzonden via het netwerk.
Stap 6: Deze aanval detecteren
Deze specifieke kwetsbaarheid voor het afstemmen van accountrechten (computeraccounts die toegang hebben tot netwerkshares in plaats van gebruikersaccounts of serviceaccounts) kan worden ontdekt. Zonder de juiste tools is dit echter erg moeilijk om te doen.
Om deze categorie aanvallen te detecteren en te voorkomen, kunnen we gebruiken om groepen met computeraccounts te identificeren en vervolgens de toegang daartoe te weigeren. gaat verder en stelt u in staat om speciaal voor dit soort scenario's een melding te maken.
De onderstaande schermafbeelding toont een aangepaste melding die wordt geactiveerd telkens wanneer een computeraccount toegang krijgt tot gegevens op een bewaakte server.
Volgende stappen met PowerShell
Wil meer weten? Gebruik de ontgrendelingscode "blog" voor gratis toegang tot het volledige .
Bron: www.habr.com