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 – From an Unprivileged Domain User to Enterprise Admin

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.

Technical Dictionary

Prior to explaining the vulnerability itself, we must first understand some components which the exploit interacts with:

DCOM

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

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.

Marshalled COM objects

Marshalling is like serialization. COM objects can be marshalled in order to send them over the network.

Session 0

Each user which logs into a Windows machine gets a new session. Session 0 is the initial session that is created on startup and runs mostly services.

RemotePotato0’s Root Causes

RemotePotato0 combines two root causes for this domain privilege escalation vulnerability in Windows:

1. 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.
2. 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.

Exploit Requirements

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.
  • In order to achieve that, an attacker either must have local Administrator permissions on the computer or use a vulnerability in a program running in session 0.
• A Domain Admin must be logged in to the same computer in an interactive session.

How does RemotePotato0 combine these into an exploit?

The following stages describe a demo scenario for an attacker using RemotePotato0:

1. An attacker with an unprivileged Domain User has an open shell in session 0. On  the same computer, a Domain Admin is logged in on session 1.
2. The attacker calls CoGetInstanceFromIstorage() with a vulnerable CLSID and initializes it with an IStorage object that points to the attacker’s fake OXID Resolver. This marshals the IStorage COM object, creates the privileged COM server, and then unmarshalls the object in the server’s security context.
3. The unmarshalling of the IStorage object triggers a request to the fake OXID Resolver.
4. The fake OXID Resolver returns RPC bindings to the attacker’s fake RPC Server.
5. At this point, the COM server which is impersonating the Domain Admin – starts the NTLM authentication procedure with the fake RPC server.
6. The attacker uses NTLM relay in order to escalate the initial unprivileged Domain User to Enterprise Admin.

NTLM

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:

1. The client wishing to authenticate creates a hash from a real password.
2. The client sends an NTLM request for authentication.
3. The server replies with a challenge and some data attached to it.
4. The challenge for the client encrypts the data with the hashed password and sends it back to the server.
5. The server knows the used hashed method and the real password. Therefore it can solve the challenge as well, and check if the response from the client contains the correct value.

NTLM Relay

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.

SafeBreach Implementation for RemotePotato0

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.

RemotePotato0.exe

We looked at the logic implemented in the exploit proof-of-concept. RemotePotato0.exe contains 3 main features:

1. Triggering of the vulnerabilty itself which causes a request to an OXID Resolver at whichever IP we choose.
2. The fake OXID Resolver

The fake RPC server

OXID Resolution Limitation

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.

Safety and Accuracy

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 the user to the “Enterprise Admins” group
• Adding permissions to the domain object, which allows specifically for the unprivileged target user to request a DCsync

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.

Success Criteria

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.

Ready to Try a Simple Run?

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”:

• In order to run the attack, you must also set up an impersonated user using the System Setup: Settings->Attack Setup->Impersonated Users:

• Choose the RemotePotato0 attack from the Attacks Playbook.
• Select Run->Select simulators to run”

• Choose the simulators you want to run the attack on and press “Run->Run Now”

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.

References

• https://github.com/antonioCoco/RemotePotato0
• https://www.sentinelone.com/labs/relaying-potatoes-another-unexpected-privilege-escalation-vulnerability-in-windows-rpc-protocol/
• https://googleprojectzero.blogspot.com/2021/10/windows-exploitation-tricks-relaying.html