Welcome to part two of the three-part series on the Remote Desktop Protocol (RDP) honeypot I set up. In the first post, I discussed ways that RDP can be configured to be more secure (and how you should NEVER put it on the Internet). In this part, I’ll talk about what happened when my honeypot was online. The final part of the series will discuss how the honeypot was set up.

Honeypot Stats

The honeypot I set up was a Windows 7 virtual machine in a mostly default state. The system was named 'payroll,' with the only user on the system also named 'payroll' and a password of 'password.' The 'administrator' account was disabled, as is the Windows 7 default.

The honeypot was online for a little over 9.5 days. There were a lot of interesting stats generated during that time, which I’ve put into the infographic below.

One interesting event occurred late on November 25. Throughout the honeypot’s life, the 'administrator' user ID was the top account being brute-forced. However, on the 25, we had the highest number of authentication attempts occurring, but very few were for 'administrator.' Of the 2,866 attempts that occurred, only 107 were for 'administrator'—the rest of the attempts were for 1,353 other user accounts, like 'backup,' 'test,' and 'boardroom.'

Compromises

Now for the interesting data. In the time the honeypot was online, there were 46 successful authentications to it. For the majority of the successful logons, attackers didn’t do anything. A successful authentication would occur and then about 30 seconds later they would log off—no commands were executed. This is likely because the initial logons were part of a brute-force attack and they were only looking for systems for which credentials could be guessed.

There were a few sessions where the attackers interacted with the system. Since process creation logs and Sysmon were running, I had visibility into what they did. A few of the more interesting sessions are described below.

Note that a full forensic analysis was not performed on the sandbox. The goal was to get an idea of what the attackers did, not determine every possible indicator.

Attack #1 – Ransomware

What should be to no one’s surprise, the first attacker that got into the honeypot installed ransomware. After initially logging on to the system, the attacker ran the program exe.exe, which then executed win_mgr.exe, which attempted to kill and disable Windows Defender in multiple ways. Fortunately, even though some of these tools were removed by the attacker, Sysmon recorded their MD5 hashes so information could be gathered on them.

According to VirusTotal, exe.exe (MD5: 7997FEA03F98F1E9CCE6F747E5187CF2) is a dropper that is not well detected at this time. There is less information on the second program win_mgr.exe (MD5: 309FCA6881D919B429B129A6D9EA3B3E), but from the context on the honeypot, we can infer it is likely a .NET version of a different dropper for the next stage of the attack.

After initial execution, a copy of Rapid Ransomware named wupdate.exe (MD5: be9a00fa7d85b8d70e4ca26efc5030c2) was executed by win_mgr.exe. To prevent recovery of encrypted files, the Rapid Ransomware turned off automatic boot repair and deleted all shadow volume copies.

Next, Rapid Ransomware copied itself to the user’s roaming directory as info.exe and set up scheduled tasks to run it every minute and every time the user logged on. This was to ensure that even if the currently running ransomware was killed, it would be restarted shortly thereafter.

Finally, the attacker launched a tool named screensaver.exe (MD5: f9073cc6566ba11318b425a761f1ce17), which locked the desktop and then executed a few commands to clean up the files that had been copied down. Unfortunately, this succeeded as these files were not available when the virtual machine (VM) was analyzed. After these commands ran, the attacker closed their RDP connection.

From that point on, the ransomware executed every minute, would display the ransomware recovery note, and was encrypting files in the background.  

This scenario is not an unusual one. The TrustedSec Incident Response team has responded to a number of incidents in which this exact ransomware was used. The root cause for each of those incidents? RDP on the Internet.

Also take note of how quickly everything happened. The logon occurred a little over three (3) minutes prior to the first command. The ransomware started encrypting just over a minute after the first command was executed. Without automation, even if the initial logon had been detected, any organization would be hard pressed to respond without any damage occurring in that short amount of time.

The interesting thing in this case is that I did not have any instrumentation to tell me how the files got on there in the first place. The Zeek IDS (formerly Bro) was logging network traffic, but there were no accesses to any websites, nor were there any web browser executions in the honeypot. I’ll admit I was stumped as to how files got onto the system until the second compromise occurred.

Attack #2 – TSCLIENT

The next attacker actually logged on to the system a day later, but I had not yet reset the sandbox back to a good state, so the ransomware was still running. Apparently, this attacker didn’t mind because they happily went forward with their plan.

After logging in, they executed a program named csrss.exe (which wasn’t the real csrss.exe), that was located on \\tsclient\y. So, what is \\tsclient?

When using RDP, its often useful to share data or devices, such as the clipboard or local printers, between the RDP client you connect from and the RDP server you are connected to. Which data is shared is configured through the Local Resources tab in the RDP connection program. However, you can also connect local drives to the system you are connected to from within the RDP client configuration!

When a local drive is selected in the RDP configuration, it is accessed from the RDP server using the \\tsclient hostname. In the case above where the attacker accessed csrss.exe on \\tsclient\y, this means that 1) they turned on remote drive sharing and 2) they had something connected to their local Y drive. Unfortunately, I have yet to find any logs that state which, if any, drives are available from a connected RDP client.

This is one possible way the attackers copied their files onto the honeypot in the first attack. In that case, we didn’t see any expected system or network activity related to network file transfers (e.g., web browsing), so it’s possible they copied the files over using Windows Explorer and the tsclient share.

When run, csrss.exe removed any legal notices from the logon screen and reconfigured RDP to allow connections from any RDP client version. This reduced the security of the system and allowed the attacker to return more easily in the future.

The csrss.exe executable then launched another program, 8993792.exe, which added a firewall rule to allow RDP connections into the system. Around 40 seconds after that, csrss.exe logged the current user off with the shutdown command.

While both executables were removed from the system, Sysmon saved the day by recording their MD5 hashes. VirusTotal describes csrss.exe (MD5: 7651E9B35392C4F78E825D307443D5EC) as a 'HackTool' and 'RdpPatch.' The second program, 8993792.exe (MD5: 78D4E9BA8F641970162260273722C887), is a renamed version of RDPWInst.exe, the installer program from hxxp://stascorp[.]com. According to the site, this program “allows you to enable support for remote desktops (RDP Host) on home systems with reduced functionality, as well as remove the restriction on the use of parallel sessions.”

It appears that this particular attacker was only coming in to ensure RDP would be available later on. Based on research on the two (2) executables and analyzing the Bro IDS logs from this time, no unusual traffic could be found. This indicates these two (2) programs are probably not backdoors. However, more analysis would be needed before we could definitely say what they were.

The last attacker I’ll describe also set up the system to get into it later but went a bit further than any other attacker.

Attack 3 – User

The last attacker we’ll discuss logged in and immediately opened the Windows Computer Management control panel. This is the Windows GUI interface that allows you to add tasks, view events, and add or remove local users from a single location. After spending a little time in that, the attacker ran a script they had copied to the desktop named 'hide2onlyADSIAdmin.bat.'

The script added three (3) users to the system: ADSI, Task, and Admin. While all were added to the 'Remote Desktop Users' group to allow RDP access, only ADSI and Admin were added to the local Administrators group. The script also set their passwords not to expire and added ADSI and Task to the 'HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList' registry key, which prevents the account name from appearing on the logon page. Finally, the script disabled access to the 'Local Users and Groups' window.

Then the attacker ran a program named UniversalTermsrcPatch-x86.exe (MD5: 2F866893CD6F2F42BC066E9C2A41AD07). This is a program from hxxp://deepxw[.]blogspot[.]com/2009/04/universal-termsrvdll-patch.html that modifies the RDP server to remove the limit on the number of concurrent RDP connections.

Why? By default, Windows only allows one (1) RDP session at a time to an RDP server. Running UniversalTermsrcPatch-x86.exe modifies the RDP server program to remove this restriction. This would allow an attacker to connect to a compromised RDP server even if someone else—like the legitimate users—were already connected. While you can configure this in Group Policy, the advantage for the attacker in modifying the binary is that the setting would not get overwritten when Group Policy was reapplied to the server.

After patching RDP, the attacker launched Internet Explorer. They first accessed the vars.hotjar.com site, which appears to set a few cookies via JavaScrip, and nothing else. Next, they accessed the authentication page for paychex.com, but as far as I could tell they did not attempt to log in. Finally, the attacker downloaded, installed, and launched Chrome. However, no additional network activity was seen.

Once the attacker had finished accessing the Internet, they rebooted the system at a command prompt.

Conclusion

This honeypot was an excellent example of how dangerous it is to put an RDP server on the Internet. In only nine (9) days, there were over 58,000 logon attempts for 4,980 different users. Chances are high that any organization that has an RDP server on the Internet has at least a few of those user accounts that immediately open them up to risk.

The honeypot also showed the methodologies, tactics, and goals of each of the attackers. The first attacker was only interested in getting onto the system and launching their ransomware for financial gain. No persistence was established (outside of knowing the credentials they logged in as), and once the ransomware was running, they logged off.

The goal of the second and third attackers, however, was to establish persistence on the system. The second attacker did this by modifying the RDP server to allow multiple connections and nothing else—likely hoping the credentials they knew would be valid at a later date. The third attacker, however, was not taking that chance. Not only did they modify the RDP server, they added multiple users they could use to log in at a later time.

TrustedSec’s Incident Response team has seen these tactics in multiple engagements, so these were not unique to the honeypot. In the honeypot’s case, it was the solitary system on a segmented network. However, we have worked cases where organizations have had their entire enterprise compromised due to these same issues, so the threat is very real.

In the final post of this series, I will talk about how the honeypot was created, the mistakes that were made, and what the future holds.