While it’s true that threat actors are constantly innovating, it’s also true that, with a hacker mindset, attackers are always looking for the easy way in. There’s no need to reinvent the wheel or detonate a zero day when you can just as easily ‘live off the land’ and keep your best exploits under wraps. In many cases, attackers can simply scrape credentials to use without getting detected by traditional security tools.
In this post, I will share a real attack method we have seen deployed in the wild on a number of occasions. The attackers utilize a Remote Desktop (RDP) connection to drop Mimikatz, an open source tool capable of scraping passwords from a Windows environment. The attack is able to bypass many legacy AV out there, as it uses the legitimate Windows RDP protocol, which a lot of commercial security tools will whitelist by default.
What is Mimikatz?
If you’re unfamiliar with Mimikatz, let’s just take a quick look at what it is and what it can do. A deeper exploration is available in our “What is Mimikatz” guide.
An open source project hosted on Github, Mimikatz is described by its author, Benjamin Delpy, as “a little tool to play with Windows security”. It is able to extract plaintext passwords, password hashes, PIN codes and Kerberos tickets from memory. The project, first made public in 2014, has been updated over the years to also include pass-the-hash and pass-the-ticket exploits, and it is also able to build Golden tickets.
How an Attack Exploits RDP
With that background in mind, let’s look at the attack method we’ve seen utilized in the wild. The case study we’ll describe here began with a detection on a SentinelOne protected machine in a client’s network. For the purposes of this case study we’ll call the machine on which the initial detection was found ‘Patient-1’.
The SentinelOne agent detected a known Mimikatz payload on Patient-1 and proceeded, as expected, to block and quarantine the threat autonomously. The following screenshot is from a demo showing how the detection would look in the management console.
Although detecting a malicious payload is not unusual, since the owner of Patient-1 is also a subscriber to our Vigilance service, we immediately began to investigate. During the investigation, we found the detected payload was dropped by an unknown binary, X.exe. This binary was delivered to Patient-1 via RDP, Microsoft’s built-in Remote Desktop protocol.
Attacking RDP is a hacker favorite as it has been found to contain a number of vulnerabilities over its lifetime which threat actors can exploit; the recently revealed BlueKeep vulnerability being a case-in-point. Attackers will always prefer to ‘live off the land’ in this way if they can, rather than deploy custom exploits, as it reduces the chance of detection by legacy AV and other unsophisticated security solutions that can still, unfortunately, be found in many enterprise situations.
Stealing Passwords, Killing Processes
After investigating X.exe, we saw that it was a password encrypted archive containing a bundle of both Process Hacker and Mimikatz.
Tools like Process Hacker are popular among developers and malware researchers, so if we looked deeper into the provenance of X.exe, we discovered that it had been dropped by RDP from another Windows server, a machine we’ll refer to as ‘Patient-0’.
Our analysis of the compromise of Patient-0 showed a similar pattern to Patient-1, but with an important difference. Patient-0 had been infected from an external RDP connection.
By leveraging SentinelOne’s Deep Visibility Threat Hunting platform, the investigation team were able to see thousands of external RDP attempts from various internet IPs unknown to the client. This pattern of network traffic is typical of an RDP brute force attack.
Stopping an Attack In Its Tracks
Why had the initial attack vector gone through Patient-0 rather than Patient-1? Unfortunately, Patient-0 was not restricted to VPN connections only, nor did it have a rate limit to slow down or deflect a brute force attack on the RDP service of that machine. Moreover, Patient-0 had no two-factor (2FA) or multi-factor authentication (MFA) security layer, and – crucially – Patient-0 was not protected by a SentinelOne agent.
Once the malicious actors had gained access to Patient-0, they were able to deploy the toolkit of Process Hacker and Mimikatz. From there, they were able to gain admin credentials from that machine and begin pivoting to other machines on the internal network via RDP.
Fortunately, the story had a happy ending as those machines were protected by SentinelOne. As a result, the attack was stopped from infecting those machines and from spreading further across the client’s network, despite the fact that the attempt to compromise these machines via RDP was using valid credentials scraped from Patient-0.
Conclusion
From this real-life story, we can learn a few valuable lessons. First, no machine should have open, non-rate limited services exposed to the internet. 2MFA is also a must-have.
Access to common services like RDP needs to be monitored and controlled, preferably equipping all servers and endpoints with an active EDR solution capable of dealing with emerging threats and ‘living off the land’ attacks.
The presence of tools like Mimikatz and other malicious frameworks such as Metasploit, COM-based rootkits like Koadic and similar requires immediate attention, network quarantine of infected machines and emergency triage.
SentinelOne offers a best-in-class solution to handle all these situations, with behavioral AI and active EDR. As this case study shows, there is no substitute for autonomous protection in today’s threatscape. If you’d like to see how SentinelOne can help protect your organisation, help yourself to a free demo today.
