DOUBLEPULSAR over RDP: Baselining Badness on the Internet

That’s good news, right? Well, I’d say that’s a qualified “yes.” As I mentioned, it’s easy to change the implant so that it doesn’t respond to the normal magic bytes and we simply wouldn’t see it. Also, DOPU doesn’t survive a system restart, which means that hosts could have been compromised and backdoored in the past but that the backdoor isn’t currently active.

Irrespective of the results, data provides us with a baseline that we can compare future scans against to know how things are changing.

Observations of DOPU traffic

Another way that Rapid7 Labs provides context is via visibility into what tools and techniques attackers use against our honeypots and what they do once they get in. We know that attempts to locate DOPU over SMB are common. How common? Our honeypots saw 375,000 DOPU PING (discovery / are you there?) commands yesterday alone.

That number isn’t an anomaly: We haven’t seen a day much below 200,000 going back six months.

That volume can likely be attributed to the widespread infection of hosts by WannaCry and other malware that then installed DOPU-over-SMB. Given how prevalent that malware was, searching for a host that already had the SMB version of DOPU is likely to be worth an attacker’s time to code into tooling or implement in future malware.

With that in mind, to provide a similar view for RDP we added explicit DOPU-over-RDP coverage to our honeypots in December and looked back over the prior months for some artifacts that the Equation Group tools and certain third-party scripts were known to leave behind.

The only traffic we saw were our own scanners. That’s great news and not terribly surprising given the lack of tooling for (and general awareness of) DOPU over RDP. As in the case of the Sonar, scans like this provide us with a baseline to work with going forward.

Practical guidance

Normally, we like to leave people with practical guidance related to the risk that we are discussing. In this case, it will be a bit more general than normal since we’re not talking about a vulnerability that can be patched but rather a backdoor that was left behind once someone had already gotten in.

Prevention

Disable RDP anywhere it isn’t used. This is pretty standard guidance for any service you don’t need. Attackers can’t walk through a door that doesn’t exist.

Don’t expose RDP to the internet. Leverage a VPN or gateway technology to enable access to RDP services if possible. If you must expose RDP to the internet, use network Access Control Lists (ACLs) to limit which network addresses can connect.

Enable Network Level Authentication (NLA). This setting requires authentication prior to connecting to RDP services. It breaks many RDP-related exploits and attacker tools while also improving the service’s overall security by requiring TLS and strong authentication methods. Our Sonar studies show that a significant number of RDP services still use Standard RDP or TLS security.

Finally, implement a risk management program to deploy patches and implement mitigating controls in a timely manner. It’s generally better to spend resources on patch management and other risk mitigation than in triage, incident response, and recovery. Internet-facing hosts should generally be among the first production systems to be addressed.

Detection

Detection of DOPU traffic is sort of a mixed bag. While there appears to be good coverage for detecting network traffic related to DOPU over SMB, I don’t see the same level of IDS/IPS coverage for DOPU over RDP. There’s also the complication that an attacker can try to leverage TLS Security instead of Standard security and the sensor will not be able to see the attack. That last part applies to pretty much all RDP exploits.

You can use William Vu’s new DOPU-over-RDP Metasploit module to scan your networks. You can use the check function to find the hosts and the Neutralize implant target to remove the DOPU implant. You can also reboot the host as the implant won’t survive a restart.

Interested in this research? Looking to collaborate? Questions? Comments? Leave them below or reach out via [email protected]!