Using PowerShell to elevate local account privileges

Privilege escalation is the use by an attacker of current account rights to obtain an additional, usually higher level of access in the system. Although privilege escalation may be the result of exploiting zero-day vulnerabilities, or the work of top-notch hackers conducting a targeted attack, or a maliciously disguised malware, but most often this is due to incorrect configuration of the computer or account. Developing an attack further, attackers exploit a number of individual vulnerabilities, which together can lead to catastrophic data leakage.

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 privileges, as this:

• Makes their accounts more vulnerable to various attacks.
• Makes these very attacks much more serious.

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

Step 1. Reverse DNS name resolution via PowerShell

By default, PowerShell is installed on many local workstations and on most Windows servers. And although it is not without exaggeration, it is considered an incredibly useful tool for automation and control, it is equally capable of turning into an almost invisible fileless malware (a hacking program that leaves no trace of the attack).

In our case, the attacker begins to perform network reconnaissance using the PowerShell script, sequentially going over the network's IP address space, trying to determine if the given IP is allowed to the host, and if so, what is the host's network name.
There are many ways to accomplish this task, but using the Get-ADComputer cmdlet is a reliable 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 the speed of work in large networks causes problems, then a DNS callback can be used:

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

This method of enumerating nodes on a network is very popular, since most networks do not use a zero-trust security model and do not track internal DNS requests for suspicious bursts of activity.

Step 2: Choosing a Target

The end result of this step is to get a list of the host names of the servers and workstations that can be used to continue the attack.



Judging by the name, the 'HUB-FILER' server seems to be a worthy goal, since Over time, file servers tend to accumulate a large number of network folders and excessive access to too many people.

Browsing using Windows Explorer allows us to determine if the shared folder is open, but our current account cannot access it (we probably only have rights to the listing).

Step 3: Learn the ACL

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

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

Result of performance:



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

Step 4: Identification of Accounts

By running Get-ADGroupMember , we can get all the members of this group:

 Get-ADGroupMember -identity Helpdesk 

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

Step 5: Use PSExec to work from a computer account

Microsoft's PsExec Sysinternals allows you to execute commands in the context of the SYSTEM @ HUB-SHAREPOINT system account, which, as we know, is a member of the Helpdesk task force. That is, we just need to perform:

 PsExec.exe -s -i cmd.exe 

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

Step 6: Detect this attack

This particular account rights setting vulnerability (computer accounts that access shared network folders instead of user accounts or service accounts) can be detected. However, without the right tools, this is very difficult.

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

The screenshot below shows a user notification that will be triggered every time a computer account accesses data on a monitored server.

Next steps using PowerShell

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