Technical Case Study: The Tale of Privilege Escalation vs the Unstartable Service

Using this browser session, Neuvik Operators had access to a web front end, which typically would provide limited ability for a (simulated) malicious attacker to perform further movement. Since this instance utilized a web browser, though, several Citrix “escapes” were possible. One of them was as simple as opening the download folder (Ctrl + J).

 

By leveraging this cheap browser trick, access to the underlying infrastructure was achieved, as noted in the below screenshot:

 

 

In normal circumstances, the next step for the Operators performing the penetration test would be to attempt to achieve the execution of arbitrary commands. However, conventional scripting interpreters such as cmd.exe, powershell.exe, wscript.exe and others were application controlled, preventing successful execution.

 

 

Interestingly, the Explorer task bar could be used to spawn arbitrary LOLBAS (Living Off The Land Binaries, Scripts and Libraries — tools and executables included as standard within the operating system), including Notepad. The use of Notepad then allowed Neuvik to create .BAT files (batch scripts that stored commands to be executed in serial order). These did achieve execution, but only using rudimentary commands, as creating a full .BAT script seemed to error out. Screenshots below showcase this approach:

 

 

Further attack paths were stymied in this client’s environment, due to strict network segmentation, making infiltration of tooling and exfiltration of data impossible via normal mechanisms.

 

Thankfully, the command line program certutil never fails to disappoint when other protections are in place. Using certutil, Neuvik Operators were able to Base64 Encode payloads, and use the Edge URL bar window to copy and paste Base64 strings to the Citrix Edge VDI. This allowed Neuvik Operators to ultimately infiltrate a PowerShell runspace file that could be compiled with MSBuild.

 

In turn, this granted unrestricted PowerShell-like functionality. Since PowerShell allows for the decoding and execution of Base64 encoded scripts, this gave Neuvik Operators an opportunity for exploitation. In some environments, further obfuscation could have been performed using the ability to execute arbitrary C# code to perform encryption or decryption at runtime, but that was not a requirement impacting Neuvik’s approach in this environment.

 

 

As offensive practitioners will know, one of the first steps adversaries take when landing on a new system is to enumerate the system and identify any misconfigurations that could lead to trivial privilege escalation. In this environment, Neuvik Operators identified an interesting (and slightly ironic) privesc opportunity: an unrestrictive Discretionary Access Control List (DACL) on the folder that hosted the winlogbeat binary, which in turn was being run as a service (within the context of the SYSTEM user).

 

As this folder was user writeable, an obvious preliminary exploit approach would be to simply replace the legitimate winlogbeat executable (e.g., winlogbeat6.8.3.exe) with a malicious one; however, this was not possible as the binary was in use, preventing the file from being overwritten due to an existing handle to the file.

 

The only alternative would be to perform a Dynamic Link Library (DLL) hijack on the binary, which required further inspection. Thankfully, exfiltration to enable this approach was not needed as winlogbeat is downloadable for free on the Elastic website. Reviewing the underlying binary during offline analysis identified interesting hijack opportunities in DLLs loaded at runtime, as noted in the screenshot below:

 

 

Please note that this is not a vulnerability in winlogbeat, but simply a representation of how Windows loads DLLs. This reflects how the Windows loader (as well as other operating systems) establish DLL search and load order. Many standard DLL’s used by binaries reside in system32, but the library search path, even for these standard libraries, first looks for the DLLs in the application’s current working directory…

 

Using the visible information provided, Neuvik Operators opted to create a tiny DLL that would add a user to the local administrator group on the Citrix VDI. The code needed to do this is quite simple, as shown below.

 

 

In other circumstances, a process injection DLL containing command and control (C2) code would work here as well (provided you do not place the code in DLLMain, which would cause loader lock). Since the network in this environment was segmented, no C2 communication could reliably be established, but privesc was sufficient to enable further exploitation.

 

After creating the payload, it was time to “fix” (rewrite) the DLL metadata as well as the function exports using Invoke-DLLClone, as shown below.

 

 

With the new version.dll compiled, Neuvik Operators Base64 encoded the payload and decoded it back on the target.

 

 

With that crucial step now complete, the only remaining thing needed to finish the exploit chain was to sideload the DLL, triggering the privilege escalation. This required restarting the service so that the new instance loaded the library from its working directory: something that Neuvik Operators did not have the access required to perform.

 

Instead, they explored several options, such as restarting the system (thwarted by access denied errors), or raising an NtRaiseHardError (using an undocumented windows API) to cause a “blue screen of death” (BSoD), and in turn force a reboot. When neither of these approaches worked, they also tried using NotMyFault (a sysinternals tool designed to cause a BSoD). Shoutout to @hackingLZ for the suggestion!

 

Unfortunately, none of these methods worked as each of them required privileges that the low privilege account to which Neuvik Operators had access did not permit, whether local admin or SeShutDown privileges at the least. For a moment all hope seemed lost, other than biding time waiting for the system to reboot, either during a maintenance window or when required by policy.

 

Then, Neuvik Operators came up with another idea: resource exhaustion. Resource exhaustion is not a new concept; the most famous example would be a forkbomb, used to cause a Denial of Service attack in which a process continually replicates itself to deplete available system resources. As there was no other way of achieving the privilege escalation, Neuvik first cleared it with the client’s Risk Avoidance team (this was also a staging environment), and then performed a resource exhaustion attack using a very simple.BAT file.

 

 

After running this script, the VDI instance ultimately ran out of memory and rebooted itself, giving the Neuvik Operators administrator access on the Citrix Edge VDI instance finally achieving privilege escalation.

 

 

While in this case the client did a lot of things correctly (proper segmentation, low privileged context and application allow-listing), a weak DACL and standard default application allow-listing caused their downfall. Defense in depth is a very strong tactic to deter adversaries, once it’s implemented it is however crucial to audit your environment and perform baselining to further tighten the security posture of the organization.

 

We hope you enjoyed this detailed walk-through highlighting an interesting privilege escalation avenue our Advanced Assessments team discovered during a recent assessment.

 

If you’re interested in learning more or testing your own environment, reach out to us at contact@neuvik.com or visit us online at www.neuvik.com.