☑️Enumeration
Situational Awareness
When placed in any situation, whether in our day-to-day lives or during a project such as a network penetration test, it is always important to orient ourselves in space and time. We cannot function and react effectively without an understanding of our current surroundings. We require this information to make informed decisions about our next steps to operate proactively instead of reactively. When we land on a Windows or Linux system intending to escalate privileges next, there are several things we should always look for to plan out our next moves. We may find other hosts that we can access directly, protections in place that will need to be bypassed, or find that certain tools will not work against the system in question.
Network Information
We can find out if the machine is dual-homed, meaning if it has interfaces in two or more networks, if so we will know there might be a chance for us to move laterally to another network. We should check the IP addresses, the arp table to see what other machines this machine has been communicating with. If our current host is used by admins, we might find out other hosts that the admin in this host were connecting to using remote desktop tools. We can also view the routing table to understand the current network and surrounding networks.
ipconfig /allarp -aroute printEnumerating Protections
Most modern environments have some sort of anti-virus or Endpoint Detection and Response (EDR) service running to monitor, alert on, and block threats proactively. Before we try any exploits or attack paths, if we know what protection mechanisms are in place we will be able to make informed decisions to make sure our attacks work properly.
Many organizations also implement application whitelisting allowing only certain applications and file types. We are talking about the use of software like cmd or PS. One of the tools that's used it called AppLocker. We can use the GetAppLockerPolicy cmdlet to enumerate the local, effective (enforced), and domain AppLocker policies.
Early enumeration and a deep understanding of the client's environment and workarounds against common AV and EDR solutions can save us time during a non-evasive engagement and make or break an evasive engagement.
Windows Defender status
PS C:\htb> Get-MpComputerStatus
AMEngineVersion : 1.1.17900.7
AMProductVersion : 4.10.14393.2248
AMServiceEnabled : True
AMServiceVersion : 4.10.14393.2248
AntispywareEnabled : True
AntispywareSignatureAge : 1
AntispywareSignatureLastUpdated : 3/28/2021 2:59:13 AM
AntispywareSignatureVersion : 1.333.1470.0
AntivirusEnabled : True
AntivirusSignatureAge : 1
AntivirusSignatureLastUpdated : 3/28/2021 2:59:12 AM
AntivirusSignatureVersion : 1.333.1470.0
BehaviorMonitorEnabled : False
ComputerID : 54AF7DE4-3C7E-4DA0-87AC-831B045B9063
ComputerState : 0
FullScanAge : 4294967295
FullScanEndTime :
FullScanStartTime :
IoavProtectionEnabled : False
LastFullScanSource : 0
LastQuickScanSource : 0
NISEnabled : False
NISEngineVersion : 0.0.0.0
NISSignatureAge : 4294967295
NISSignatureLastUpdated :
NISSignatureVersion : 0.0.0.0
OnAccessProtectionEnabled : False
QuickScanAge : 4294967295
QuickScanEndTime :
QuickScanStartTime :
RealTimeProtectionEnabled : False
RealTimeScanDirection : 0
PSComputerName :List AppLocker Rules
Test AppLocker Policy
Initial Enumeration
We can escalate privileges to one of the following depending on the system configuration and what type of data we encounter:
The highly privileged NT AUTHORITY\SYSTEM account, or LocalSystem account which is a highly privileged account with more privileges than a local administrator account and is used to run most Windows services.
The built-in local administrator account. Some organizations disable this account, but many do not. It is not uncommon to see this account reused across multiple systems in a client environment.
Another local account that is a member of the local Administrators group. Any account in this group will have the same privileges as the built-in administrator account.
A standard (non-privileged) domain user who is part of the local Administrators group.
A domain admin (highly privileged in the Active Directory environment) that is part of the local Administrators group.
Enumeration is the key to privilege escalation. This Windows commands reference is very handy for performing manual enumeration tasks.
Key Data Points
OS name: Knowing the type of Windows OS (workstation or server) and level (Windows 7 or 10, Server 2008, 2012, 2016, 2019, etc.) will give us an idea of the types of tools that may be available (such as the PowerShell version), or lack thereof on legacy systems. This would also identify the operating system version for which there may be public exploits available.
Version: As with the OS version, there may be public exploits that target a vulnerability in a specific version of Windows. Windows system exploits can cause system instability or even a complete crash. Be careful running these against any production system, and make sure you fully understand the exploit and possible ramifications before running one.
Running Services: Knowing what services are running on the host is important, especially those running as NT AUTHORITY\SYSTEM or an administrator-level account. A misconfigured or vulnerable service running in the context of a privileged account can be an easy win for privilege escalation.
System Information
Tasklist
We can check what applications are running on the system using the tasklist command:
There will be lots of standard servies such as Session Manager Subsystem (smss.exe), Client Server Runtime Subsystem (csrss.exe), WinLogon (winlogon.exe), Local Security Authority Subsystem Service (LSASS), and Service Host (svchost.exe), etc. Knowing these will help us narrow down and identify non-standard applications and services which might open up ways to escalate privileges.
In the example above, we would be most interested in the FileZilla FTP server running and would attempt to enumerate the version to look for public vulnerabilities or misconfigurations such as FTP anonymous access, which could lead to sensitive data exposure or more. Other processes such as MsMpEng.exe, Windows Defender, are interesting because they can help us map out what protections are in place on the target host that we may have to evade/bypass.
Environment Variables
We can use the set command to list all the environment variables.
One of them is the PATH variable. It usually holds paths to necessary applications such as Python or Java to run other applications. So if we have write privileges to such files we can perform attacks like DLL Injections against other applications.
Remember, when running a program, Windows looks for that program in the CWD (Current Working Directory) first, then from the PATH going left to right. This means if the custom path is placed on the left (before C:\Windows\System32), it is much more dangerous than on the right.
Other one is the HOMEPATH variable. In enterprises, this will often be a file share. Navigating to the file share itself may reveal other directories that can be accessed. It is not unheard of to be able to access an "IT Directory," which contains an inventory spreadsheet that includes passwords. Additionally, shares are utilized for home directories so the user can log on to other computers and have the same experience/files/desktop/etc. (Roaming Profiles). This may also mean the user takes malicious items with them.
Viewing Configuration Information
We can use the systeminfo command to get a lot of information.
It will tell us if this host is a VM or not. Under the Hotfixes we will get lots of patches starting with KB. Searching about them will tell us if the host was recently patched or not. The System Boot Time and OS Version can also be checked to get an idea of the patch level. If the box has not been restarted in over six months, chances are it is also not being patched.
Additionally, many guides will say the Network Information is important as it could indicate a dual-homed machine (connected to multiple networks).
If systeminfo doesn't display hotfixes, they may be queriable with WMI using the WMI-Command binary with QFE (Quick Fix Engineering) to display patches.
We can do this with PowerShell as well using the Get-Hotfix cmdlet.
Installed Programs
WMI can also be used to display installed software. This information can often guide us towards hard-to-find exploits. Is FileZilla/Putty/etc installed? Run LaZagne to check if stored credentials for those applications are installed. Also, some programs may be installed and running as a service that is vulnerable.
We can, of course, do this with PowerShell as well using the Get-WmiObject cmdlet.
Display Running Processes - netstat
The netstat command will display active TCP and UDP connections which will give us a better idea of what services are listening on which port(s) both locally and accessible to the outside. We may find a vulnerable service only accessible to the local host (when logged on to the host) that we can exploit to escalate privileges.
Users and Groups Information
To see what users are currently logged-in if they are active or idle
Who is the current user?
What privileges our current user has?
Has our user inherited any rights through their group membership? Are they privileged in the Active Directory domain environment, which could be leveraged to gain access to more systems?
Get all other users in the system. Maybe our current user has another account in the same host with a slightly different name (bob, bob_adm) and we can check for credential re-use:
Knowing what non-standard groups are present on the host can help us determine what the host is used for, how heavily accessed it is, or may even lead to discovering a misconfiguration such as all Domain Users in the Remote Desktop or local administrators groups.
It is worth checking the detail information of a group, especially for non-standard groups, as they can have credentials in the group description, comments etc. Even if its for a non-admin user it might help us find other vectors for privilege escalation:
And of course, understanding the password policy and other information about this account:
Communication With Processes
One of the best ways to escalate privilege on a system is by abusing applications and processes that are running on it. For example an IIS or XAMPP web server, uploading a shell and running it. Generally, this is not an administrator but will often have the SeImpersonate token, allowing for Rogue/Juicy/Lonely Potato to provide SYSTEM permissions.
What are Access Tokens?
In Windows, access tokens are used to describe the security context (security attributes or rules) of a process or thread. The token includes information about the user account's identity and privileges related to a specific process or thread. When a user authenticates to a system, their password is verified against a security database, and if properly authenticated, they will be assigned an access token. Every time a user interacts with a process, a copy of this token will be presented to determine their privilege level.
Network Connections
The most common way to interact with processes is using network sockets. We can use the netstat command to list all the TCP and UDP ports on the system that are accessible both from inside and outside.
The main thing to look for with Active Network Connections are entries listening on loopback addresses (127.0.0.1 and ::1) that are not listening on the IP Address (10.129.43.8) or broadcast (0.0.0.0, ::/0). The reason for this is network sockets on localhost are often insecure due to the thought that "they aren't accessible to the network." The one that sticks out immediately will be port 14147, which is used for FileZilla's administrative interface. By connecting to this port, it may be possible to extract FTP passwords in addition to creating an FTP Share at c:\ as the FileZilla Server user (potentially Administrator).
One of the best examples of this type of privilege escalation is the Splunk Universal Forwarder, installed on endpoints to send logs into Splunk. The default configuration of Splunk did not have any authentication on the software and allowed anyone to deploy applications, which could lead to code execution. Again, the default configuration of Splunk was to run it as SYSTEM$ and not a low privilege user. For more information, check out Splunk Universal Forwarder Hijacking and SplunkWhisperer2.
Another overlooked but common local privilege escalation vector is the Erlang Port (25672). Erlang is a programming language designed around distributed computing and will have a network port that allows other Erlang nodes to join the cluster. The secret to join this cluster is called a cookie. Many applications that utilize Erlang will either use a weak cookie (RabbitMQ uses rabbit by default) or place the cookie in a configuration file that is not well protected. Some example Erlang applications are SolarWinds, RabbitMQ, and CouchDB. For more information check out the Erlang-arce blogpost from Mubix
Named Pipes
The other way processes communicate with each other is through Named Pipes. Pipes are essentially files stored in memory that get cleared out after being read. Cobalt Strike uses Named Pipes for every command (excluding BOF). Essentially the workflow looks like this:
Beacon starts a named pipe of \.\pipe\msagent_12
Beacon starts a new process and injects command into that process directing output to \.\pipe\msagent_12
Server displays what was written into \.\pipe\msagent_12
Cobalt Strike did this because if the command being ran got flagged by antivirus or crashed, it would not affect the beacon (process running the command). Often, Cobalt Strike users will change their named pipes to masquerade as another program. One of the most common examples is mojo instead of msagent. One of my favorite findings was finding a named pipe start with mojo, but the computer itself did not have Chrome installed. Thankfully, this turned out to be the company's internal red team. It speaks volumes when an external consultant finds the red team, but the internal blue team did not.
More details about pipes
Pipes are used for communication between two applications or processes using shared memory. There are two types of pipes, named pipes and anonymous pipes. An example of a named pipe is \\.\PipeName\\ExampleNamedPipeServer. Windows systems use a client-server implementation for pipe communication. In this type of implementation, the process that creates a named pipe is the server, and the process communicating with the named pipe is the client. Named pipes can communicate using half-duplex, or a one-way channel with the client only being able to write data to the server, or duplex, which is a two-way communication channel that allows the client to write data over the pipe, and the server to respond back with data over that pipe. Every active connection to a named pipe server results in the creation of a new named pipe. These all share the same pipe name but communicate using a different data buffer.
We can use the tool PipeList from the Sysinternals Suite to enumerate instances of named pipes.
We can do the same on PowerShell
After obtaining a listing of named pipes, we can use Accesschk to enumerate the permissions assigned to a specific named pipe by reviewing the Discretionary Access List (DACL), which shows us who has the permissions to modify, write, read, or execute a resource. Let's take a look at the LSASS process. We can also review the DACLs of all named pipes using the command .\accesschk.exe /accepteula \pipe\.
We see that only Administrators have FILE_ALL_ACCESS.
Named Pipe Attack Example
Let's walk through an example of taking advantage of an exposed named pipe to escalate privileges. This WindscribeService Named Pipe Privilege Escalation is a great example. Using accesschk we can search for all named pipes that allow write access with a command such as accesschk.exe -w \pipe\* -v and notice that the WindscribeService named pipe allows READ and WRITE access to the Everyone group, meaning all authenticated users.
Confirming with accesschk we see that the Everyone group does indeed have FILE_ALL_ACCESS (All possible access rights) over the pipe.
From here, we could leverage these lax permissions to escalate privileges on the host to SYSTEM.
Last updated