Recently during a CTF I found a few users were unfamiliar with abusing setuid on executable on Linux systems for the purposes of privilege escalation. If an executable file on Linux has the “suid” bit set when a user executes a file it will execute with the owners permission level and not the executors permission level. Meaning if you find a file with this bit set, which is owned by a user with a higher privilege level than yourself you may be able to steal their permissions set.
I previously posted about breaking out of restrictive desktop environments to gain access to a CMD shell or acess to Powershell. However sometimes the environment is even tighter, for example with Citrix environments you may not even be on a desktop but simply have an application exposed to you.
I posted earlier about Privilege Escalation through Unquoted Service Paths and how it’s now rare to be able to exploit this in the real world due to the protected nature of the C:\Program Files and C:\Windows directories. It’s still possible to exploit this vulnerability, but only when the service executable is installed outside of these protect directories which in my experience is rare. Writing that post though got me thinking about another method of privilege escalation which I think is a little more common to see – DLL Hijacking.
Many organisations “lock-down” their desktop environments to reduce the impact that malicious staff members and compromised accounts can have on the overall domain security. Many desktop restrictions can slow down an attacker but it’s often possible to “break-out” of the restricted environment. Both assessing and securing these desktop environments can be tricky, so I’ll run you through how I assess them here, highlight some of the tricks and the methodology that I use with the intention that both breakers and defenders can get a better look at their options.
A couple of days ago I posted an article about the first steps an attacker would likely take to perform a desktop breakout attack. Where that post left off was at the point of looking for privilege escalation from domain user to local administrator.
What are LLMNR and NetBIOS-NS? They’re both methods of resolving hostnames to IP addresses. On your network if you try to contact a system by name first of all DNS will be used, but if that fails LLMNR will be attempted followed by NetBIOS. LLMNR is the successor to NetBIOS and it supports IPv6 and multicast addresses.
Pre-Execution Boot, or PXE, is a method of booting a workstation machine by loading an operating system across the network. If PXE boot can be enabled (often it is enabled by default, even when machines are restricted from booting CDs or USB Devices) then an stripped down Linux operating system can be loaded over the network and used to compromise the target.