Darkfeed Case Study: How A Financial Services Customer Identified A Supply Chain Compromise
Threat actors constantly look for vulnerabilities in systems and networks. This includes efforts to crack RDP connections, since with remote access to an internal network, an actor can cause quite a bit of damage. With RDP credentials, an actor can exfiltrate sensitive data, deploy ransomware, or use the resources as a staging ground for a future attack.
Cybersixgill’s Darkfeed includes compromised RDP addresses within its stream of malicious IOCs. Receiving this information moments after they appear on a dark web forum enables the feed’s consumers to block them at early stages, before they are weaponized and used in an attack.
On February 15, a Darkfeed customer (a $2B+ revenue financial services company) received an alert that they had outgoing network traffic to an IP address that was flagged by Darkfeed as having a compromised RDP connection. The customer noted that this RDP address belonged to a trusted partner of theirs—a government entity—and requested that we further check this issue.
Every Darkfeed IOC includes a post ID, a unique identifier that allows the feed consumer to open the post from where the IOC originated in Cybersixgill’s Investigative Portal. This empowers a deeper investigation to understand the full context behind the indicator.
As it turns out, the IP address appeared in a post from the same day that contained 1,496 RDP credentials, including IP address, company name, username, and password.
This IP address was indeed listed as belonging to their partner. It stated that the username was user3 and the password was password.
Based on the arbitrary nature of the IP addresses and the insecure username-passwords included in the intel item, our understanding is that the paste includes credentials resulting from an automated scan using dictionary attacks to crack RDP passwords. Any attacker could have used any of the 1,496 RDP credentials from the paste to initiate a large-scale attack.
Armed with Darkfeed, our customer was able to relay this information to the partner. Without this intel, the partner might have become just another government entity hit by ransomware via an exposed RDP connection. However, with this critical, timely intelligence, the partner was able to remediate the situation.
But what about the other 1,495 RDP connections? How and in what way will their owners ultimately find out that credentials to their internal network have been posted on the underground?