Using PowerShell to Increase Local Account Privileges

Privilege escalation is the use by an attacker of the current account rights to obtain an additional, usually higher level of access to the system. Despite the fact that privilege escalation may be the result of exploitation of zero-day vulnerabilities, or the work of first-class hackers conducting a targeted attack, or a properly disguised malware, but most often this happens due to incorrect configuration of the computer or account. Developing the attack further, attackers exploit a number of separate vulnerabilities, which together can lead to a catastrophic data leak.

Why shouldn't users have local administrator rights?

If you are a security specialist, 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 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 the rights of a local administrator on the system under investigation: either through an exploit or because the machines were not properly protected.

Step 1. Reverse DNS name resolution through PowerShell

By default, PowerShell is installed on many local workstations and on most Windows servers. Although 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 (hacking program that does not leave traces of an attack).

In our case, the attacker begins to perform network reconnaissance using the PowerShell script, sequentially sorting the IP address space of the network, trying to determine whether this IP is allowed to the host, and if so, what is the network name of this host.
There are many ways to accomplish this task, but using the Get- cmdletADComputer is a reliable option because it returns a truly rich dataset 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 the DNS system callback can be used:

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

This method of listing hosts on a network is very popular since most networks do not use a zero-confidence security model and do not track internal DNS requests for suspicious activity spikes.

Step 2: Goal Selection

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



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

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

Step 3: Learn the ACL

Now on our HUB-FILER host and the target share folder, we can run the PowerShell script to get the ACL. 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

Execution result:



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

Step 4: Identify Accounts

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

Get-ADGroupMember -identity Helpdesk

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

Step 5: Use PSExec to work from a computer account

PsExec from Microsoft 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, it is enough for us to perform:

PsExec.exe -s -i cmd.exe

Well, then you have full access to the target folder \\ HUB-FILER \ share \ HR, since you work 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 transferred over the network.

Step 6: detect this attack

This particular vulnerability for setting account privileges (computer accounts accessing 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 each 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 Fundamentals .