Privilegium-eskalering er en hackers brug af de aktuelle rettigheder til en konto for at få yderligere, normalt et højere niveau af adgang til systemet. Selvom privilegieeskalering kan være resultatet af udnyttelse af nul-dages sårbarheder, eller arbejdet fra førsteklasses hackere, der udfører et målrettet angreb, eller smart forklædt malware, skyldes det oftest fejlkonfiguration af computeren eller kontoen. Ved at udvikle angrebet yderligere bruger angribere en række individuelle sårbarheder, som tilsammen kan føre til et katastrofalt datalæk.
Hvorfor skulle brugere ikke have lokale administratorrettigheder?
Hvis du er en sikkerhedsprofessionel, kan det virke indlysende, at brugere ikke skal have lokale administratorrettigheder, da dette:
- Gør deres konti mere sårbare over for forskellige angreb
- Gør de samme angreb meget mere alvorlige
Desværre er dette for mange organisationer stadig et meget kontroversielt spørgsmål og er nogle gange ledsaget af heftige diskussioner (se f.eks. ). Uden at gå ind i detaljerne i denne diskussion mener vi, at angriberen har opnået lokale administratorrettigheder på det system, der undersøges, enten gennem en udnyttelse eller fordi maskinerne ikke var ordentligt beskyttet.
Trin 1 Omvendt DNS-opløsning med PowerShell
Som standard er PowerShell installeret på mange lokale arbejdsstationer og på de fleste Windows-servere. Og selvom det ikke er uden overdrivelse, at det betragtes som et utroligt nyttigt automatiserings- og kontrolværktøj, er det lige så i stand til at forvandle sig selv til et næsten usynligt (et hackingprogram, der ikke efterlader spor efter angrebet).
I vores tilfælde begynder angriberen at udføre netværksrekognoscering ved hjælp af et PowerShell-script, sekventielt itererende over netværkets IP-adresserum, og forsøger at bestemme, om en given IP løses til en vært, og i så fald, hvad er netværksnavnet på denne vært.
Der er mange måder at udføre denne opgave på, men ved at bruge cmdlet ADComputer er en solid mulighed, fordi den returnerer et virkelig rigt sæt data om hver node:
import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq ‘10.10.10.10’}Hvis hastigheden på store netværk er et problem, kan et DNS-tilbagekald bruges:
[System.Net.Dns]::GetHostEntry(‘10.10.10.10’).HostName
Denne metode til at angive værter på et netværk er meget populær, da de fleste netværk ikke bruger en nul-tillid sikkerhedsmodel og ikke overvåger interne DNS-anmodninger for mistænkelige udbrud af aktivitet.
Trin 2: Vælg et mål
Slutresultatet af dette trin er at få en liste over server- og arbejdsstationværtsnavne, der kan bruges til at fortsætte angrebet.
Ud fra navnet virker 'HUB-FILER'-serveren som et værdigt mål, siden over tid akkumulerer filservere som regel et stort antal netværksmapper og overdreven adgang til dem af for mange mennesker.
At browse med Windows Stifinder giver os mulighed for at registrere tilstedeværelsen af en åben delt mappe, men vores nuværende konto kan ikke få adgang til den (sandsynligvis har vi kun rettigheder til at blive listet).
Trin 3: Lær ACL'er
Nu, på vores HUB-FILER-værts- og måldeling, kan vi køre et PowerShell-script for at hente ACL. Vi kan gøre dette fra den lokale maskine, da vi allerede har lokale administratorrettigheder:
(get-acl hub-filershare).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –autoUdførelsesresultat:
Af den ser vi, at gruppen Domænebrugere kun har adgang til listen, men Helpdesk-gruppen har også rettigheder til at ændre.
Trin 4: Kontoidentifikation
Løb , kan vi få alle medlemmer af denne gruppe:
Get-ADGroupMember -identity Helpdesk
På denne liste ser vi en computerkonto, som vi allerede har identificeret og allerede har fået adgang til:
Trin 5: Brug PSExec til at køre som en computerkonto
fra Microsoft Sysinternals giver dig mulighed for at udføre kommandoer i sammenhæng med systemkontoen SYSTEM@HUB-SHAREPOINT, som vi ved er medlem af Helpdesk-målgruppen. Det vil sige, vi skal bare gøre:
PsExec.exe -s -i cmd.exeNå, så har du fuld adgang til målmappen HUB-FILERshareHR, da du arbejder i sammenhæng med HUB-SHAREPOINT-computerkontoen. Og med denne adgang kan dataene kopieres til en bærbar lagerenhed eller på anden måde hentes og transmitteres over netværket.
Trin 6: Opdagelse af dette angreb
Denne særlige sårbarhed ved indstilling af kontoprivilegier (computerkonti, der får adgang til netværksshares i stedet for brugerkonti eller tjenestekonti) kan opdages. Men uden de rigtige værktøjer er dette meget svært at gøre.
For at opdage og forhindre denne kategori af angreb, kan vi bruge at identificere grupper med computerkonti i dem, og derefter nægte adgang til dem. går videre og giver dig mulighed for at oprette en meddelelse specifikt til denne slags scenarier.
Skærmbilledet nedenfor viser en brugerdefineret meddelelse, der udløses, hver gang en computerkonto får adgang til data på en overvåget server.
Næste trin med PowerShell
Vil du vide mere? Brug "blog" oplåsningskoden for gratis adgang til det fulde .
Kilde: www.habr.com