Microsoft works with researchers to detect and protect against new RDP exploits
Credit to Author: Eric Avena| Date: Thu, 07 Nov 2019 21:05:30 +0000
On November 2, 2019, security researcher Kevin Beaumont reported that his BlueKeep honeypot experienced crashes and was likely being exploited. Microsoft security researchers collaborated with Beaumont as well as another researcher, Marcus Hutchins, to investigate and analyze the crashes and confirm that they were caused by a BlueKeep exploit module for the Metasploit penetration testing framework.
BlueKeep is what researchers and the media call CVE-2019-0708, an unauthenticated remote code execution vulnerability in Remote Desktop Services on Windows 7, Windows Server 2008, and Windows Server 2008 R2. Microsoft released a security fix for the vulnerability on May 14, 2019.
While similar vulnerabilities have been abused by worm malware in the past, initial attempts at exploiting this vulnerability involved human operators aiming to penetrate networks via exposed RDP services.
Microsoft had already deployed a behavioral detection for the BlueKeep Metasploit module in early September, so Microsoft Defender ATP customers had protection from this Metasploit module by the time it was used against Beaumont’s honeypot. The module, which appears to be unstable as evidenced by numerous RDP-related crashes observed on the honeypot, triggered the behavioral detection in Microsoft Defender ATP, resulting in the collection of critical signals used during the investigation.
Microsoft security signals showed an increase in RDP-related crashes that are likely associated with the use of the unstable BlueKeep Metasploit module on certain sets of vulnerable machines. We saw:
- An increase in RDP service crashes from 10 to 100 daily starting on September 6, 2019, when the Metasploit module was released
- A similar increase in memory corruption crashes starting on October 9, 2019
- Crashes on external researcher honeypots starting on October 23, 2019
Figure 1. Increase in RDP-related service crashes when the Metasploit module was released
Coin miner campaign using BlueKeep exploit
After extracting indicators of compromise and pivoting to various related signal intelligence, Microsoft security researchers found that an earlier coin mining campaign in September used a main implant that contacted the same command-and-control infrastructure used during the October BlueKeep Metasploit campaign, which, in cases where the exploit did not cause the system to crash, was also observed installing a coin miner. This indicated that the same attackers were likely responsible for both coin mining campaigns—they have been actively staging coin miner attacks and eventually incorporated the BlueKeep exploit into their arsenal.
Our machine learning models flagged the presence of the coin miner payload used in these attacks on machines in France, Russia, Italy, Spain, Ukraine, Germany, the United Kingdom, and many other countries.
Figure 2. Geographic distribution of coin miner encounters
These attacks were likely initiated as port scans for machines with vulnerable internet-facing RDP services. Once attackers found such machines, they used the BlueKeep Metasploit module to run a PowerShell script that eventually downloaded and launched several other encoded PowerShell scripts.
Figure 3. Techniques and components used in initial attempts to exploit BlueKeep
We pieced together the behaviors of the PowerShell scripts using mostly memory dumps. The following script activities have also been discussed in external researcher blogs:
- Initial script downloaded another encoded PowerShell script from an attacker-controlled remote server (5.135.199.19) hosted somewhere in France via port 443.
- The succeeding script downloaded and launched a series of three to four other encoded PowerShell scripts.
- The final script eventually downloaded the coin miner payload from another attacker-controlled server (109.176.117.11) hosted in Great Britain.
- Apart from downloading the payload, the final script also created a scheduled task to ensure the coin miner stayed persistent.
Figure 4. Memory dump of a PowerShell script used in the attacks
The final script saved the coin miner as the following file:
C:WindowsSystem32spoolsvchost.exe
The coin miner connected to command-and-control infrastructure at 5.100.251.106 hosted in Israel. Other coin miners deployed in earlier campaigns that did not exploit BlueKeep also connected to this same IP address.
Defending enterprises against BlueKeep
Security signals and forensic analysis show that the BlueKeep Metasploit module caused crashes in some cases, but we cannot discount enhancements that will likely result in more effective attacks. In addition, while there have been no other verified attacks involving ransomware or other types of malware as of this writing, the BlueKeep exploit will likely be used to deliver payloads more impactful and damaging than coin miners.
The new exploit attacks show that BlueKeep will be a threat as long as systems remain unpatched, credential hygiene is not achieved, and overall security posture is not kept in check. Customers are encouraged to identify and update vulnerable systems immediately. Many of these unpatched devices could be unmonitored RDP appliances placed by suppliers and other third-parties to occasionally manage customer systems. Because BlueKeep can be exploited without leaving obvious traces, customers should also thoroughly inspect systems that might already be infected or compromised.
To this end, Microsoft customers can use the rich capabilities in Microsoft Defender Advanced Threat Protection (Microsoft Defender ATP) to gain visibility on exploit activities and defend networks against attacks. On top of the behavior-based antivirus and endpoint detection and response (EDR) detections, we released a threat analytics report to help security operations teams to conduct investigations specific to this threat. We also wrote advanced hunting queries that customers can use to search for multiple components of the attack.
The post Microsoft works with researchers to detect and protect against new RDP exploits appeared first on Microsoft Security.