Attribution: It’s one of the most difficult parts of trying to tell people, “hey… your fly is open.”
I’m not talking about the whole 21st century “spin the big wheel of attack attribution” game that various security firms like to play (“Aaaaaaaand… ittttttsssss… CHINA, No! Wait! It looks like it might spin past CHINA and on to… NORTH KOREAAAAAAAAA!!”)
What I’m talking about here is real attack attribution. Identifying the owner of a compromised system that is attacking others on the ‘Net so I can contact them and get them to clean it up. It’s about making the 'Net a better place, not about making headlines.
While I’m sure that there is little to no guesswork involved in any of the high profile “nation state” attack attributions that have taken place over the past few years (cough, cough… The bad guys may be sophisticated enough to hack our systems, but they can’t be smart enough to evade our monitoring, or to misdirect us into an incorrect attribution…)
Sadly, in my case, there’s a lot of guesswork involved: WHOIS sucks in a plethora of ways, reverse-DNS rarely works, and abuse@ ISP emails are a frickin' black hole.
It’s tough, so I need to get a little creative at times.
Here’s a little trick that has been fairly helpful with identifying compromised Windows systems being used for RDP brute-force scanning. Generally, those boxes have, themselves, been compromised by an RDP brute-force attack and oftentimes have only 3389/TCP open to the ‘Net.
Enter the pentester’s BFF: Nmap.
I’ve found it incredibly helpful to take a look at the SSL certificate that RDP connections use to identify the server you’re connecting to. I’ve tried reading through Microsoft’s literature to figure out just how “default” support for RDP over SSL/TLS may be, but reading MS docs gives me a headache. I think that it’s been the default since Windows 2003 SP1 (which makes me REALLY wonder about the systems I’ve found that DON’T seem to support SSL/TLS). In any case, grabbing the SSL cert (self-signed by default) will sometimes cue me into what the machine itself thinks it is called.
The problem is, out of the box, Nmap doesn’t really consider port 3389/TCP a worthy target from which to gank SSL certificate details. We can fix this little oversight in a couple of different ways:
Either way, running the “ssl-cert” script against 3389/TCP will give you output like the following:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
The “common name” found in that particular scan, coupled with some IP address geolocation information allowed me to contact some folks who had been compromised, making the Internet a safer place and getting me one step closer to the day when I am rightfully canonized by the Church of Flying the Spaghetti Monster as the Patron Saint of Compromised Hosts.
Update: I’ve since learned that this is fixed in the current version (7+) of Nmap. The “fix” is still relevant if you’re running an older version of Nmap, and the idea of getting identifying information via RDP is always valid :-)