Blog
By
IONSEC Team

Reverse Engineering GodPotato (MSASCui.exe)

November 10, 2024

4

min read

Abstract

Privilege escalation is a critical technique employed by attackers to gain unauthorized access to higher system privileges, often leading to significant security breaches.

This paper examines a recently disclosed method utilized by the GodPotato tool, which exploits vulnerabilities in the Distributed Component Object Model (DCOM) to elevate privileges on Windows systems. The goal of this paper is to analyse the underlying

mechanisms of the "God Potato" privilege escalation technique and examine its implications for system security.

Who is the Potato family

The "Potato" family of exploits includes several privilege escalation techniques designed to leverage vulnerabilities in Windows services, especially around impersonation and

privilege delegation. Tools like RottenPotato, JuicyPotato, and SweetPotato have targeted vulnerabilities in the Windows COM and DCOM services, exploiting

misconfigurations in the SeImpersonatePrivilege permission.

These exploits enable attackers to escalate privileges from service or local accounts to system, the highest level of privilege on Windows machines. Each "Potato" variant adapts to different Windows versions and configurations, maintaining relevance as Windows security updates aim to close older vulnerabilities.

The family has been widely studied in both offensive security and defensive research, illustrating the risks of misconfigured privilege assignments in complex enterprise environments.

Prerequisites:

  • ImpersonatePrivilege permission, which is often granted to web and database services by default.

Using the GodPotato tool, we can execute any command with system-level privileges.

Background

RPC (Remote Procedure Call)

It is a protocol that enables a program to execute code or request services on a remote system (server) as if it were calling a local function.

DCOM (Distributed Component Object Mode)

It is a Microsoft technology that extends the Component Object Model (COM) to support communication among software components distributed across networked computers.

How it works

The GodPotato exploit consists of four key phases. First, it initializes the GodPotato context. Next, it hooks the RPC server dispatch table. In the final phases it elevates its privileges by setting up a pipe server and initiating the client process to connect to it.

GodPotato context

The first phase of GodPotato is the context creation. During this phase it gathers data to manipulate and delegate RPC functions.

The GodPotato context initialization flow involves enumerating all process’s DLLs to locate combase.dll. Once located, it searches for the RPC_SERVER_INTERFACE structure in memory by scanning for a unique byte sequence that combines its size and GUID.

The rest of the GodPotato context initialization flow extracts data from the RPC_SERVER_INTERFACE structure and its inner structure MIDL_SERVER_INFO, which will be used in subsequent phases.

For example, the data extracted in the context initialization phase is used to determine target function’s parameters count. This value is then used to create a delegated function with the proper memory signature (The same function is wrapped in a wrapper function with varying argument counts to create an appropriate delegation function for each possible UseProtseqFunctionParamCount value).

Hooking the RPC

Using the pointer to the RPC dispatch table, and the proper delegation function signature gathered in the previous phase, GodPotato hooks the RPC dispatch table to replace the target function with its own function.

Hooking the RPC ends with RPC’s dispatch table pointing to the following code (wrapped by the delegation function):

This code above constructing a custom DualStringArray (see fields below) with the pipe from GodPotato context and a specific endpoint. Returning a pointer to this array from

the hooked function replaces the standard binding information that the RPC server uses.

This function will be later invoked, in the Trigger phase.

Setting the pipe server

After hooking the RPC dispatch table, this phase creates the pipe server and executes it as a new thread.

The PipeServer method is part of the GodPotato context initialized before. This method implements a named pipe server that can impersonate connected clients and attempts to elevate its privileges by finding a system-level token.

At first, this method creates a security descriptor, which sets the security attributes of the named pipe to allow all users full access at named pipe creation.

After the named pipe is created, the PipeServer method starts listening to the named pipe and waits for a client connection. When a client process connects to the named

pipe the server impersonates the client and enumerates client’s tokens to find a system-level token.

After locating the desired token, the GodPotato process creates a new Windows identity from this privileged token, thereby elevating its own process privileges.

Triggering the client

In this phase, the GodPotato technique brings together all the previous components to achieve privilege escalation. After hooking the RPC dispatch table and setting up a pipe server (which is responsible for elevating the process's privileges by impersonating the client) the crucial missing piece is obtaining a connection from a client process that has system-level privileges.

First, it creates a new GodPotatoTrigger instance which creates a general COM IUnknown interface pointer and a COM object moniker (IMoniker) for the object

identified by the previous IUnknown pointer. These objects are used by COM and DCOM mechanisms to identify and bind objects.

After the GodPotatoTrigger instance is initialized, calling the Trigger function starts a call flow that ends with unmarshalling a crafted serialized object. The unmarshalling

process is an internal mechanism that uses the ResolveOxid API to resolve the OXID

(critical part when communicating with remote COM objects).

When the server gets a ResolveOxid request, it checks if there is already registered protocol (appears in the binding string of the serialized object) with the specified OXID. If not registered, the function invokes the UseProtSeq method.

When hooking the RPC dispatch table, GodPotato has changed the pointer to the UseProtSeq method. The delegated function UseProtSeq is pointing to, returns a crafted binding string referring to the pipe server initialized in the previous phase

(instead of the original binding address and endpoint).

Unmarshalling the crafted COM object replaces the client process's binding string, causing the client process to connect to the impersonating pipe server. The

impersonating pipe server then uses the client's token to elevate its privileges to system level.