RemotePotato0 - A Complex Active Directory Attack in BAS
Breach and Attack Simulation (BAS) tools are crucial in order to make sure an organization is safe. Organizations purchase many security controls. However, until recently, the first time these security controls were tested under the current configuration of the organization was only when a live threat arrived - BAS is changing that.
BAS is here in order to simulate these attacks beforehand. We want to simulate a complete attacker's behavior in the most accurate and safest way possible to ensure that organizations are truly protected by their security controls. We chose to share the process of creating a Microsoft Active Directory attack called RemotePotato0 in order to introduce how easy it is to test your security controls using SafeBreach against a complex Domain Admin privilege escalation attack with only a few clicks.
RemotePotato0 is an exploit for a recent domain privilege escalation vulnerability found by Antonio Cocomazzi and Andrea Pierini from SentinelLABS. It allows attackers to escalate an unprivileged user to an Enterprise Admin. This vulnerability has never been labeled with a CVE. Why is that? Because Microsoft has no intention of fixing it! That means that each and every Microsoft Active Directory environment that uses NTLM is vulnerable to RemotePotato0.
Prior to explaining the vulnerability itself, we must first understand some components which the exploit interacts with:
Distributed Component Object Model (DCOM) is Microsoft’s protocol for creating remote objects called COM objects and calling their methods. It’s implemented on top of MSRPC.
OXID resolution is the process of obtaining the remote procedure call (RPC) binding information that is required to communicate with the object exporter. You can think of it as a DNS for finding COM objects.
Marshalling is like serialization. COM objects can be marshalled in order to send them over the network.
Each user which logs into a Windows machine gets a new session. Session 0 is the initial session which is created on startup and runs mostly services.
RemotePotato0 combines two root causes for this domain privilege escalation vulnerability in Windows:
User Impersonation. When a COM object with certain vulnerable CLSIDs is created in session 0 in Windows, the local COM server - which creates the object - impersonates the user which is logged in on that computer’s first interactive session.
COM Marshalling. Marshalled COM objects in Windows can contain a field which specifies the bindings for the OXID Resolver. The process of unmarshalling a COM object includes asking the OXID Resolver for the COM object’s RPC bindings.
In order for RemotePotato0 to be used to exploit these root causes, the following must be true:
The attacker must have the ability to run code in session 0 on a computer in the domain.
A Domain Admin must be logged in to the same computer in an interactive session.
The following stages describe a demo scenario for an attacker using RemotePotato0:
NTLM relay is necessary in order to execute this exploit. In order to understand NTLM relay, we must first understand what it is and how it works. Windows NT LAN Manager (NTLM) is an authentication protocol used in Active Directory domains. It is constructed in the following main stages:
NTLM relay is a man-in-the-middle attack between an NTLM client and server. The attack is used mostly in order to escalate privileges. To successfully execute this kind of attack, a highly privileged user in the domain should be manipulated to authenticate to an authentication server that is under the control of an attacker using the NTLM protocol. In order to perform NTLM relay, all an attacker needs to do is to act like a proxy between the client and the server. By providing the solved challenge, the attacker is authenticated by the server with the privileges of the client.
As mentioned before, we wanted to add RemotePotato0 to our Attacker's Playbook in order to give our users an option to simulate this exploit easily. This goal was extended to doing so with the click of a button. For this, we also needed it to support our customers’ existing platform without requiring further configuration. In the original proof of concept, the NTLM relay and port forwarding were done using standard tools on Linux. For the convenience of SafeBreach users, we extended and automated this test for use with either Windows or Linux simulators.
We looked at the logic implemented in the exploit proof-of-concept. RemotePotato0.exe contains 3 main features:
The OXID resolution request needs to address
127.0.0.1(localhost), because the request is made from the same computer that the OXID Resolver is running on. Starting from Windows 10 1809 & Windows Server 2019, it is not possible to send an OXID resolution request to a port other than 135. The problem is that the service ‘rpcss’ is the one listening on port 135. The solution for that is setting up port forwarding which listens on port 135 on another machine in order to make the OXID resolution request and then redirect it back to the machine and port RemotePotato0.exe is listening on.
Our purpose is always to simulate the attack in the safest way possible. Thus, we must revert all the permissions we add to the unprivileged Domain User. The functionality inside ntlmrelayx.py escalates the target user in the following ways:
Adding a user to the group of Enterprise Admin is enough to prove that the exploit worked. We also wanted to escalate the DCsync permissions, in order to simulate the default and most common flow of the exploit. Knowing that, we needed to add a capability which reverts the permissions. We added the capability of taking a snapshot of the user groups and user permissions on the domain object at any point of the attack. At the end of any attack, that capability is run, restoring the permissions and groups to what they were before and ensuring that we don't harm the original configuration of the domain.
In order to check if the attack was made successfully in our product, we checked that the user was added to the "Enterprise Admins" groups. If it was, then the attack reports that it was not stopped by any security control or configuration change.
Before you run the attack, make sure that there is a Domain Admin logged in to a session on the target Windows machine you are testing. You can use the “query sessions” command in the cmd terminal of the target computer in order to list the active sessions and users.
Choose or create a Domain User which is not a Domain Admin - in this case, a user named "lala":
The user will be added to the "Enterprise Admins" group using the exploit:
Don't be alarmed though, because a second later the permission for the user to do a DCsync will be removed and the original groups will be restored:
It’s as simple as that! With just a few clicks of a button, you can simulate the RemotePotato0 attack accurately and safely.