Privilege escalation is the act of a malicious actor using the existing account rights to gain additional, typically higher-level access within the system. Although privilege escalation can result from exploiting zero-day vulnerabilities, or from top-tier hackers conducting targeted attacks, or from well-disguised malware, it most often occurs due to misconfigured computer systems or accounts. As attackers further the attack, they exploit a series of individual vulnerabilities, which collectively may lead to catastrophic data leaks.
Why Users Should Not Have Local Administrator Rights?
If you are a security professional, it may seem obvious that users should not have local administrator rights, as this:
- Makes their accounts more vulnerable to various attacks
- Makes these attacks much more severe
Unfortunately, for many organizations, this remains a highly contentious issue often accompanied by heated discussions (see for example, ). Without delving into the details of this discussion, we believe that the attacker has gained local administrator rights on the examined system: either through an exploit or because the machines were not adequately secured.
Step 1. Reverse DNS Name Resolution via PowerShell
By default, PowerShell is installed on many local workstations and on most Windows servers. And while it is somewhat exaggeratedly considered an incredibly useful tool for automation and management, it can equally be transformed into an almost invisible (a hacking tool that leaves no trace of the attack).
In our case, the attacker begins to perform network reconnaissance using a PowerShell script, sequentially scanning the IP address range of the network, trying to determine whether a given IP resolves to a node, and if so, what the network name of that node is.
There are many ways to accomplish this task, but using the cmdlet ADComputer on usaldusväärne variant, kuna see pakub tõeliselt rikkalikku andmete kogumit iga sõlme kohta:
import-module activedirectory Get-ADComputer -property * -filter { ipv4address -eq ‘10.10.10.10’}Kui suurte võrkude töökiirus põhjustab probleeme, siis võib kasutada pöörd DNS süsteemikutsungit:
[System.Net.Dns]::GetHostEntry(‘10.10.10.10’).HostName
See meetod sõlmede loetlemiseks võrgus on väga populaarne, kuna enamik võrke ei kasuta nullil põhinevat turvamudelit ega jälgi sisemisi DNS päringute kahtlasi tegevushoope.
Samm 2: Sihtmärgi valik
Selle sammuga saadud lõpp-tulemus on nimekiri serveritest ja tööjaamadest, mida saab kasutada rünnaku jätkamiseks.
Nime põhjal tundub server ‘HUB-FILER’ olevat väärtuslik sihtmärk, kuna failiserverid koguvad tavaliselt aja jooksul suures koguses võrgukaustasid ja neile on liiga paljude inimeste üleliigne juurdepääs.
Windowsi Eksploraatori vaatamine võimaldab meil määrata, kas avatud jagatud kaust on olemas, kuid meie praegune konto ei saa sellele juurde pääseda (tõenäoliselt on meil ainult loetlemise õigused).
Samm 3: ACL-i uurimine
Nüüd saame meie HOSTanud HUB-FILER ja sihtkausta share puhul käivitada PowerShelli skripti ACL-i loendi saamiseks. Saame seda teha oma kohalikust masinast, kuna me juba omame kohaliku administraatori õigusi:
Get-Acl hub-filershare | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited,InheritanceFlags –autoTeostamise tulemus:
Sellest näeme, et Domeeni kasutajate grupil on juurdepääs ainult loetlemiseks, kuid grupil Helpdesk on ka õigused muutmiseks.
Samm 4: Kontode tuvastamine
Käivitades , saame me selle grupi kõik liikmed:
Get-ADGroupMember -identity Helpdesk
Selles nimekirjas näeme juba identifitseeritud arvutikontot, millele oleme juba juurde pääsenud:
Samm 5: Kasutame PSExec'i arvutikonto kontekstis toimimiseks
Microsoft Sysinternals'i teenusest võimaldab käivitada käske süsteemikonto SYSTEM@HUB-SHAREPOINT kontekstis, mille liikmeks me teame, et on sihtgrupp Helpdesk. See tähendab, et piisab lihtsalt järgmistest käskudest:
PsExec.exe -s -i cmd.exeSeejärel on teil täielik juurdepääs sihtkaustale HUB-FILERshareHR, kuna töötate HUB-SHAREPOINT arvutikonto kontekstis. Selle juurdepääsuga saab andmeid kopeerida kaasaskantavatele salvestusseadmetele või muul viisil võrgus edastada.
Samm 6: Rünnaku tuvastamine
See konkreetne kontode õiguste seadistamise haavatavus (arvutikontod, mis pääsevad juurde ühistele võrgukaustadele, mitte kasutajakontodele või teeninduskontodele) on tuvastatav. Kuid ilma õigeid tööriistu on seda väga keeruline teha.
Rünnakute avastamiseks ja ennetamiseks saame kasutada arvutikontode gruppide tuvastamiseks neis ning seejärel juurdepääsu sulgemiseks. minnaks edasi ja võimaldatakse luua teatise just sellise stsenaariumi jaoks.
Alloleval ekraanipildil on näidatud kasutaja teade, mis aktiveerub iga kord, kui arvutikonto pääseb jälgitaval serveril andmetele juurde.
Järgmised sammud PowerShelli abil
Kas soovite rohkem teada? Kasutage avakoodi „blog” tasuta juurdepääsuks täielikule .
Allikas: habr.com
