ManageEngine ADAudit - Reverse engineering Windows RPC to find CVEs - part 1 / RPC


This research consist of three parts covering different areas namely developing a custom RPC client, reverse engineering and a bit of cryptography.

When this research started, the objective was actually to find a new way to leverage an old CVE, however digging into the product a new rabbit hole appeared, leading to a new vulnerability.

This part of the research explains intricate parts of Remote Procedure Calls (RPC) in Windows environments and how to develop a custom client.



ManageEngine is a company with around 50 different products ranging from full SIEM solutions to Mobile Device Management systems with 280 000+ customers world-wide. This article will deep-dive into ADAudit Plus, which is a product used for real-time monitoring of Active Directory, Windows file servers and Windows configuration change auditing.

ADAudit can remotely access event logs and other statistics using standard remote interaction tools available in Windows. However, for comprehensive visibility and specialized functions on the targeted machines, it is necessary to install an agent on the audited Windows systems, specifically the ADAuditPlusAgent.

When this research started, the objective was actually to find a new way to leverage an old CVE, however digging into the product a new rabbit hole appeared, leading to a new vulnerability..

As the old CVE was fixed, the research had to be conducted on an older version of ADAudit, more precisely the version 7050 released December 2021

ManageEngine have a penchant for building applications on top of Tomcat with Java which makes it a good target to practice some source code analysis and reverse engineering. Lets begin digging.


For those who are not familiar with Java and decompiling, here is Shelltrail’s methodology:

Find all .jar files you would like to assess and download them to your Unix host. The jar files will most likely be stored in the installation directory of the product that is being assessed.

user@adpen1:~/adaudit/7$ ls -la
total 8036
drwxr-xr-x 2 user user    4096 Dec  1 08:36 .
drwxr-xr-x 5 user user    4096 Dec  1 08:35 ..
-rw-r--r-- 1 user user  997934 Dec  1 08:36 AdventNetADAPClient.jar
-rw-r--r-- 1 user user   12040 Dec  1 08:36 AdventnetADAPFilter.jar
-rw-r--r-- 1 user user  139792 Dec  1 08:36 AdventNetADAPJspClient.jar
-rw-r--r-- 1 user user 4534195 Dec  1 08:36 AdventnetADAPServer.jar
-rw-r--r-- 1 user user   15735 Dec  1 08:36 AdventnetADAPService.jar
-rw-r--r-- 1 user user   68066 Dec  1 08:36 AdventnetADAPStartUp.jar
-rw-r--r-- 1 user user  686147 Dec  1 08:36 AdventNetClientComponents.jar
-rw-r--r-- 1 user user  290027 Dec  1 08:36 AdventNetClientFramework.jar
-rw-r--r-- 1 user user   65094 Dec  1 08:36 AdventNetIdiomsGallery.jar
-rw-r--r-- 1 user user  294662 Dec  1 08:36 AdventNetNPrevalent.jar
-rw-r--r-- 1 user user  104252 Dec  1 08:36 AdventNetRssLibrary.jar
-rw-r--r-- 1 user user  157667 Dec  1 08:36 AdventNetTableComponents.jar
-rw-r--r-- 1 user user  781984 Dec  1 08:36 AdventNetUpdateManagerInstaller.jar
-rw-r--r-- 1 user user   22935 Dec  1 08:36 AdventNetWebClientCore.jar
-rw-r--r-- 1 user user   13413 Dec  1 08:36 AdventNetWebClientRangeNavigator.jar
-rw-r--r-- 1 user user   13809 Dec  1 08:36 AdventNetWebClientTree.jar

Jar-files is an acronym for Java Archive. It is a file format based on the popular ZIP file format and is used for archiving many files into one.

So yes, it is possible to extract the jar file with a zip tool and retrieve the content:

user@adpen1:~/adaudit/7$ 7z l AdventNetADAPClient.jar

2021-12-30 21:37:22 D....            0            0  com/adventnet/sym/adsm/common/webclient/tracker
2021-12-30 21:37:22 D....            0            0  com/adventnet/sym/adsm/common/webclient/tree
2021-12-30 21:37:22 D....            0            0  com/adventnet/sym/adsm/common/webclient/util
2021-12-30 21:37:22 .....         3836         1804  com/adventnet/sym/adsm/auditing/webclient/compliance/ComplianceDEReportHandler.class
2021-12-30 21:37:22 .....        43842        17323  com/adventnet/sym/adsm/auditing/webclient/compliance/ComplianceReportHandler.class
2021-12-30 21:37:22 .....         1857          764  com/adventnet/sym/adsm/auditing/webclient/ember/api/ADAPAPIServlet.class
2021-12-30 21:37:22 .....         1884          774  com/adventnet/sym/adsm/auditing/webclient/ember/api/ADAPAgentAPIServlet.class

This will give you the class files stored in the Jar, however class files are Java code compiled into Java bytecode which is interpreted by Java Virtual Machine (JVM) and therefore is not human readable.

jd-gui is a good tool for decompiling individual Jar files into a human readable format for analysis but it does not scale well when you have many files.

To automate this process, jd-cli can be used to unzip and decompile the Jar files - making them searchable and viewable.

user@adpen1:~/adaudit/7$ jd-cli *.jar 
09:51:11.097 INFO  com.github.kwart.jd.cli.Main - Decompiling AdventNetADAPClient.jar
09:51:11.107 INFO  com.github.kwart.jd.output.ZipOutput - ZIP file output will be initialized - AdventNetADAPClient.src.jar
09:51:14.930 INFO  com.github.kwart.jd.output.ZipOutput - Finished with 129 class file(s) and 1 resource file(s) written.

user@adpen1:~/adaudit/7$ mkdir src
user@adpen1:~/adaudit/7$ cd src
user@adpen1:~/adaudit/7/src$ find ../ -name '*src.jar' -exec unzip -o {} \;
Archive:  ../AdventNetUpdateManagerInstaller.src.jar
  inflating: META-INF/MANIFEST.MF    
  inflating: com/adventnet/tools/update/installer/images/context_help.png  
  inflating: com/adventnet/tools/update/installer/images/context_install.png  
  inflating: com/adventnet/tools/update/installer/images/error.png  
  inflating: com/adventnet/tools/update/installer/images/help_icon.png  
  inflating: com/adventnet/tools/update/installer/images/import.png  
  inflating: com/adventnet/tools/update/installer/images/info.png 

From this point, the analysis of the source code could be initiated.


What shifted the focus from the initial target was the interest in the functionality to interact and fetch information from Windows machines with the ADAuditPlusAgent installed. The ADAuditPlusAgent has many features which can be activated from the ADAudit server, one of these are a so called SessionMonitoring feature. This feature starts a process that takes screenshots at a set interval, and sends them to the central server. This allows the server to create videos of configuration state changes and connect them with events. As an example it is possible for the low privileged user in the agent machine can get a video session of an administrator deleting a critical configuration file.

Sounds like a fun feature to review, doesn’t it?

When enabling the SessionMonitoring feature from the ADAudit server while analysing all the traffic sent to the agent with wireshark an RPC interaction via named pipes was discovered.


Hmm interesting! Lets first dwelve into the history of DCE RPC.


DCE RPC or Distributed Computing Environment Remote Procedure Call is a protocol used in client to server interactions and is general term in computer science and not something only available on Windows Systems.

Microsoft however wanted their own flavour and developed MSRPC (Microsoft Remote Procedure Call) with the introduction of Windows NT, first released in 1993. RPC is an old protocol but it is the foundation of how inter-computer communication works in Windows environments.

So basically how RPC works is that a Interface Definition Language (IDL) is defined that exposes procedures to clients. The IDL also defines how the client should interact with parameters such as a UUID, version and optionally a handle.

    implicit_handle(handle_t ImplicitHandle)

interface hello
    void HelloProc([in, string] unsigned char * pszString);
    void Shutdown(void);

The first part which is called the IDL header. This header should contain a UUID to not conflict with other RPC interfaces, a version number, and can utilize three different handles; explicit, implicit and automatic.

The second part, also known as the IDL body states the procedures that the client can interact with.

When connecting to the server a binding to the RPC interface must be initialized. This can be either ncacn_ip_tcp, ncalrpc or ncacn_np

ncacn_ip_tcp uses plain TCP communication to interact with the server. For this binding to work the RPC server must be configured with a static TCP port that is reachable. This does not require authentication in order to establish a connection to the RPC, leaving all authentication responsibility to the exposed procedure on the server. The initial connection to the RPC is done over TCP/135.

Example: ncacn_ip_tcp:[49670]

ncalrpc is used for local RPC interactions which should not be exposed over the network.

Example: ncalrpc:[LRPC-dfdb2238aff756a07c]

ncacn_np Lets the client and server negotiate TCP port for interaction and the negotiation occurs over SMB. Meaning this type of binding requires username and password to connect to SMB, if anonymous sessions are not enabled.

Example: ncacn_np:[\pipe\hello]


What we know up to this part is actually only that the ADAudit server is using RPC to interact with the Agents over a named pipe called ADAPAgentRpcPipe as seen in the wirehark screenshot.

What we now need to do is:

  • Create a valid IDL structure
  • Brew a large can of coffee
  • Build an RPC client
  • Guess a lot
  • Create input data that will be marshalled into a valid stub that servers RPC interface will act on.

Lets begin with the IDL structure. RpcView have everything we need to accomplish this step as the tool can decompile the IDL structure from the RPC interface. This tool should be executed on the server exposing the RPC interface:


Get the Visual Studio 2022 installer from

Choose to install Desktop developments with C++


Make sure Windows SDK is selected as this packages contains the necessary components to craft the RPC client:


Fire up a Visual Studio 2022 and initiate a C++ console app project.

Start by changing the project build options to Release and x64 in order to not require debug runtime libraries when running the compiled binary outside of the build machine.


Create a file named ADAPAgentRpcPipe.idl in the Source Files structure in Visual Studio:


Copy the decompiled IDL structure which was exported by RpcView to the newly created file.

interface DefaultIfName
	void Proc0(
		[in]long arg_0,
		[in][out]long* arg_1);

	void Proc1(
		[in]long arg_0,
		[in][string] wchar_t* arg_1,
		[in][out]long* arg_2);

	void Proc2(
		[in][out]long* arg_0,
		[in][out]long* arg_1);

Right click the file in Visual Studio and choose compile - Visual Studio will use midl.exe to compile the IDL file into C code which will handle the appropriate marshalling operations.

Marshalling is the process of converting data objects and parameters into a state that can be transmitted over a network. This is crucial when transporting complex data structures.

The data sent to the RPC server when pushing commands to the ManageEngine ADAudit Agent can actually be viewed in the DCERPC request in the Stub data section. An exception to this visibility is if the server defaults to SMB3, then event the Stub data section is encrypted. In the following image the server is using SMB2:


Back to the project; after compiling of the IDL structure there should now be three new files in the visual studio project folder:

  • ADAPAgentRpcPipe_c.c: _c for client
  • ADAPAgentRpcPipe_h.h: _h for header
  • ADAPAgentRpcPipe_s.c: _s for server


  • Create a valid IDL structure. Done.

Next up, coffee:

  • Brew a large can of coffee

With the IDL structure complete and coffee ready the next step is to build the RPC client. Microsoft provides example code specifying how to build an RPC client and server application. The public code will be used as a skeleton for our ADAuditRPC-client so it is copied to a file named adauditrpc-client.cpp under Source Files in Visual Studio (use any existing main cpp file or create a new one)

Example code:

/* file: helloc.c */
#include <stdlib.h>
#include <stdio.h>
#include <ctype.h>
#include "hello.h" 
#include <windows.h>

void main()
    RPC_STATUS status;
    unsigned char * pszUuid             = NULL;
    unsigned char * pszProtocolSequence = "ncacn_np";
    unsigned char * pszNetworkAddress   = NULL;
    unsigned char * pszEndpoint         = "\\pipe\\hello";
    unsigned char * pszOptions          = NULL;
    unsigned char * pszStringBinding    = NULL;
    unsigned char * pszString           = "hello, world";
    unsigned long ulCode;
    status = RpcStringBindingCompose(pszUuid,
    if (status) exit(status);

    status = RpcBindingFromStringBinding(pszStringBinding, &hello_ClientIfHandle);
    if (status) exit(status);
        ulCode = RpcExceptionCode();
        printf("Runtime reported exception 0x%lx = %ld\n", ulCode, ulCode);
    status = RpcStringFree(&pszStringBinding); 
    if (status) exit(status);
    status = RpcBindingFree(&hello_IfHandle);
    if (status) exit(status);


/*         MIDL allocate and free                     */
void __RPC_FAR * __RPC_USER midl_user_allocate(size_t len)
void __RPC_USER midl_user_free(void __RPC_FAR * ptr)

The first modification we need to do is to replace the filename on line 1 and line 5 #include "hello.h" to #include "ADAPAgentRpcPipe_h.h" as we have compiled our own header file created via the IDL file. In addition to we add a line with #pragma comment(lib, rpcrt4.lib") to be able to create RPC bindings.

The result:

- /* file: helloc.c */
  #include <stdlib.h>
  #include <stdio.h>
  #include <ctype.h>
- #include "hello.h" 
  #include <windows.h>

+ /* file: adauditrpc-client.cpp */
  #include <stdlib.h>
  #include <stdio.h>
  #include <ctype.h>
+ #include "ADAPAgentRpcPipe_h.h" 
  #include <windows.h>
+ #pragma comment(lib, "rpcrt4.lib")

Next step is to replace some data types and initiate variables to be used for the RPC bindings. These can be found on lines 12-19.

     RPC_STATUS status;
-    unsigned char * pszUuid             = NULL;
-    unsigned char * pszProtocolSequence = "ncacn_np";
-    unsigned char * pszNetworkAddress   = NULL;
-    unsigned char * pszEndpoint         = "\\pipe\\hello";
-    unsigned char * pszOptions          = NULL;
-    unsigned char * pszStringBinding    = NULL;
-    unsigned char * pszString           = "hello, world";
     unsigned long ulCode;

     RPC_STATUS status;
+    RPC_WSTR pszUuid = NULL;
+    RPC_WSTR pszProtocolSequence = (RPC_WSTR)L"ncacn_np";
+    RPC_WSTR pszNetworkAddress = (RPC_WSTR)L""; // Target ADAudit agent
+    RPC_WSTR pszEndpoint = (RPC_WSTR)L"\\pipe\\ADAPAgentRpcPipe";
+    RPC_WSTR pszOptions = NULL;
+    RPC_WSTR pszStringBinding = NULL;
+    //unsigned char * pszString           = "hello, world";
     unsigned long ulCode;

At line 29 we replace:

- status = RpcBindingFromStringBinding(pszStringBinding, &hello_ClientIfHandle);
+ status = RpcBindingFromStringBinding(pszStringBinding, &DefaultIfName_v1_0_c_ifspec);

And line 49:

- status = RpcBindingFree(&hello_IfHandle);
+ status = RpcBindingFree(&DefaultIfName_v1_0_c_ifspec);

The &DefaultIfName_v1_0_c_ifspec parameter is defined in the header file from our IDL compilation as we named our RPC interface DefaultIfName (Line 5 in ADAPAgentRpcPipe.idl).

The last step would be to call the correct procedures as stated in our IDL: Proc0, Proc1 or Proc2. At this point in time we have no clue what the procedures do when they are triggered on the agent side but we aim to find out.

At line 34 and 35 Microsoft’s example code calls the example procedures HelloProc() and Shutdown(). We will continue with replacing these with Proc0 and provide valid arguments to test our first ADAuditAgentRpcPipe procedure.

By reviewing our IDL structure for Proc0 we also know that the procedure takes two argument:


arg_0 with datatype long which is an integer datatype and arg_1 with datatype long* which is a pointer to a long. arg_1 is defined with [in][out] meaning that this may be output from the application.

As our IDL header structure lacks an implicit handle we need to provide a handle (&DefaultIfName_v1_0_c_ifspec) to Proc0, we’ll also instantiate variables for arg_0 and arg_1:

-    RpcTryExcept
-    {
-        HelloProc(pszString);
-        Shutdown();
-    }

+    long arg_0 = 0;
+    long arg1_pointer;
+    long* arg_1 = &arg1_pointer;
+    RpcTryExcept
+    {
+        Proc0(DefaultIfName_v1_0_c_ifspec, arg_0, arg_1);
+    }

In order for Visual Studio to reference DefaultIfName_v1_0_c_ifspec, we need to include the ADAPAgentRpcPipe_c.c file in our list of source files:


Also add the ADAPAgentRpcPipe_h.h file under Header Files.

The final project structure in Visual Studio should now look loo this:


And if every step is followed correctly the project should now build. Voil√†…


But does it actually work?

Running the binary from the command line does not print any output unless an exception is thrown but if the network traffic is analyzed with Wireshark we can see similar traffic to when the RPC interaction was triggered by the ADAudit web application.


O.. M.. G.. it seems to work!


In this part of the research we successfully created a working RPC client to interact with the ADAudit Agent. But we still don’t know what either Proc0, Proc1 or Proc2 does. In part 2, we dig into reverse engineering of the agent software in an attempt to find out what we actually can do with our newly created client.

Support us by following our LinkedIn page and get notified when new research is published:

Follow this URL to read part 2: