Using PowerShell to Elevate the Privilege of Local Accounts

Privilege escalation is the use by an attacker of the current rights of an account to gain additional, usually a higher level of access to the system. While privilege escalation can be the result of exploiting zero-day vulnerabilities, or the work of first-class hackers conducting a targeted attack, or cleverly disguised malware, it is most often due to misconfiguration of the computer or account. Developing the attack further, attackers use a number of individual vulnerabilities, which together can lead to a catastrophic data leak.

Why shouldn't users 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 those same attacks much more severe

Unfortunately, for many organizations this is still a very controversial issue and is sometimes accompanied by heated discussions (see, for example, my supervisor says all users must be local admins). Without going into the details of this discussion, we believe that the attacker gained local administrator rights on the system under investigation, either through an exploit or because the machines were not properly protected.

Step 1Reverse DNS Resolution with PowerShell

By default, PowerShell is installed on many local workstations and on most Windows servers. And while it's not without exaggeration that it's considered an incredibly useful automation and control tool, it's equally capable of transforming itself into a near-invisible fileless malware (a hacking program that does not leave traces of the attack).

In our case, the attacker begins to perform network reconnaissance using a PowerShell script, sequentially iterating over the network IP address space, trying to determine whether a given IP resolves to a host, and if so, what is the network name of this host.
There are many ways to accomplish this task, but using the cmdlet get-ADComputer is a solid option because it returns a really rich set of data about each node:

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

If speed on large networks is a problem, then a DNS callback can be used:

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

This method of listing hosts on a network is very popular, as most networks do not use a zero-trust security model and do not monitor internal DNS requests for suspicious bursts of activity.

Step 2: Choose a target

The end result of this step is to obtain a list of server and workstation hostnames that can be used to continue the attack.

From the name, the 'HUB-FILER' server seems like a worthy target, since over time, file servers, as a rule, accumulate a large number of network folders and excessive access to them by too many people.

Browsing with Windows Explorer allows us to detect the presence of an open shared folder, but our current account cannot access it (probably we only have listing rights).

Step 3: Learn ACLs

Now, on our HUB-FILER host and target share, we can run a PowerShell script to get the ACL. We can do this from the local machine, since we already have local administrator rights:

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

Execution result:

From it we see that the Domain Users group has access only to the listing, but the Helpdesk group also has the rights to change.

Step 4: Account Identification

Running Get-ADGroupMember, we can get all members of this group:

Get-ADGroupMember -identity Helpdesk

In this list we see a computer account that we have already identified and have already accessed:

Step 5: Use PSExec to run as a computer account

PsExec from Microsoft Sysinternals allows you to execute commands in the context of the SYSTEM@HUB-SHAREPOINT system account, which we know is a member of the Helpdesk target group. That is, we just need to do:

PsExec.exe -s -i cmd.exe

Well, then you have full access to the target folder HUB-FILERshareHR, since you are working in the context of the HUB-SHAREPOINT computer account. And with this access, the data can be copied to a portable storage device or otherwise retrieved and transmitted over the network.

Step 6: Detecting this attack

This particular account privilege tuning vulnerability (computer accounts accessing network shares instead of user accounts or service accounts) can be discovered. However, without the right tools, this is very difficult to do.

To detect and prevent this category of attacks, we can use DataAdvantage to identify groups with computer accounts in them, and then deny access to them. DataAlert goes further and allows you to create a notification specifically for this kind of scenario.

The screenshot below shows a custom notification that will fire every time a computer account accesses data on a monitored server.

Next steps with PowerShell

Want to know more? Use the "blog" unlock code for free access to the full PowerShell and Active Directory Basics video course.

Source: habr.com