How To Use PowerShell for Privilege Escalation with Local Computer Accounts

What is Privilege Escalation?

Privilege escalation is when an attacker is able to exploit the current rights of an account to gain additional, unexpected access. While this can be caused by zero-day vulnerabilities, state-level actors crafting attacks or cleverly disguised malware most often it’s a result of a simple account misconfiguration.

From there, attackers can escalate through a series of small vulnerabilities that when chained together result in a potentially catastrophic data breach.

Why Shouldn’t Users Have Local Admin Rights?

If you’re a security professional it might seem obvious that users shouldn’t have local admin rights as it:

• Makes their accounts more vulnerable to a variety of attacks
• Makes attacks that do occur potentially much more severe

Sadly, this is still a point of contention in many organizations, for example: see this /r/sysadmin thread – Boss Says All Users Should be Local Admins.

Because of this ongoing conversation, this tutorial starts with the assumption that an attacker has gained local admin rights: either through an exploit or because machines haven’t been properly locked down.

It’s a practical example of what can happen to your network when local admin rights are given.

Step 1: Reverse DNS Network Reconnaissance with PowerShell

PowerShell is installed by default on many local workstations and on most Windows servers. While typically considered an incredibly helpful automation and management tool, it’s equally capable of being turned into Fileless Malware.

In this case, the attacker begins with performing network reconnaissance with a PowerShell script that iterates through the IP Address Space of the network trying each IP in succession to determine if it resolves to a host and if so what is that host’s network name.

There’s a variety of means to accomplish that task, but utilizing the Get-ADComputer cmdlet is a solid option as it returns a really rich set of data about each host.

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

If speed is more of an issue (it’s a large network) a raw reverse DNS call might be used.

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

This method of enumerating hosts on a network is often used as most networks do not employ a Zero-Trust security model and are not monitoring internal DNS requests for suspicious bursts of activity.

Step 2: Picking a Target

The end result of this step is a list of server (and workstation) hostnames that can be used to inform the next action.

Based on the server names ‘HUB-FILER` seems like a strong potential target (unless exceedingly well organized and audited, over time file servers tend to accumulate additional shares with a mish-mash of permissions)

Browsing through Windows Explorer allows us to determine that there is an open share, but that our current account can’t access it (which usually equates to list permissions).

Step 3: List ACLs on the Share

Now, with a target host HUB-FILER and a target share: \share we can run a PowerShell script to enumerate the ACLs on the target. We can do this from the local machine as we’re a local admin account.

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

The result of which is:

From this, we can see that Domain Users just have List access, but that the Helpdesk group has additional Modify privileges.

Step 4: Identifying Accounts

By running Get-ADGroupMember we’re able to then pull all the members of the group.

Get-ADGroupMember -identity Helpdesk

In the list of accounts, we find a computer account matching the system that we have already gained access to:

Step 5: Use PSExec to Open a new Command Window as the Computer Account

PsExec from Microsoft Sysinternals lets you run commands in the context of the system account (which from the previous step we know is a member of the target group). This step only

PsExec.exe -s -i cmd.exe

At this point, you now have full access to the target share \\hub-filer\share\hr as you’re operating within the context of the computer account. And with this account access, data could be copied to a portable storage device or otherwise exfiltrated from the network.

Step 6: Detecting this type of attack

This particular configuration vulnerability (computer accounts accessing file shares instead of user or system accounts) is something that you should be able to detect. However, without the right tools at your disposal, it’s fiendishly hard.

To help prevent this category of attack we can use DatAdvantage to identify groups with computer accounts in them and then pull back their access. DatAlert goes a step further and will let us create a custom alert specifically for this scenario.

The screenshot below shows a custom alert that will trip whenever a computer account accesses data on a monitored server.

Next Steps with PowerShell

Want to learn more? Use unlock code ‘blog’ for free access to the full PowerShell and Active Directory Essentials video course.