* Updated October 13, 2020
In 2019, we were asked by some of our clients to perform an insider threat assessment to help them better understand their attack surface if a single system on their network were to be compromised. This is not a typical penetration test because we were given an asset, knowledge of the internal network layout, information about the organization’s crown jewels, and a list of security tools currently in place.
The Problem
We discovered during a recent assessment that FireEye’s Endpoint Security product, HX, fails to properly inspect, block, and quarantine known/commodity malware if it is run through a redirected resource in an RDP session. The agent also failed to provide any alerts during or after the malware was run (yikes). At first glance, we thought this was a mistake or a configuration issue until we confirmed in our lab, and also with FireEye, that this is a product flaw. Sadly, AV bypass is not CVE worthy.
Remote Desktop is the most common tool used to remotely manage Windows-based systems, so there is a high probability that HX customers have it enabled. Assuming an adversary already has access to your network (e.g., rogue implant, compromised host, etc.), they could move laterally to other systems via RDP and run any malware of their choice through a mapped redirected local resource, without having to bypass HX.
For demonstration purposes, we used a pre-built Mimikatz binary as it is commonly used to extract hashed and cleartext credentials from memory, and use them to move to adjacent systems; however, any malware can be run through this vector. Even Meterpreter interactive shells can be established using Metasploit (not shown in video).
Note: This is not a customer misconfiguration with the agent. HX functions as expected when malware is saved to disk, in memory, or executed off a mapped network drive. We also verified this attack vector could not be exploited with several other vendors including Bit Defender, ESET, Windows Defender, Palo Alto Traps and Crowdstrike, where the malware is detected, blocked and/or quarantined when run through a redirected RDP resource.
Test Environment
Windows 10 Build: 18393 (1909)
HX Agent Version: 31.28.4
Exploit Guard: Enabled
Malware Guard: Enabled
Workaround / Mitigation / Fix
As of October 12, 2020, FireEye has issued an update to the HX agent that addresses the identified issue. It is worth noting that this attack vector can still be exploited if the following configuration has not been enabled:
Here is the response received by FireEye on February 24, 2020:
The current version of the FireEye Agent does not scan files that are mapped from a local disk to a remote system when connecting via Remote Desktop Protocol (RDP). FireEye is evaluating mechanisms to enable such scanning and plans to include this capability in a future version of the Agent.
This issue can only be exploited by an attacker who has credentials with authorization to access the target system via RDP. Also, this issue is mitigated by the fact that the FireEye Agent analyzes more than just files. For example, an attacker can use this issue to transfer Mimikatz or a similar tool to the remote system. When the tool attempts to dump hashed credentials from the memory of the lsass process, however, the Agent Process Guard feature (if installed and enabled) can identify that activity. Similarly, the issue can be used to transfer a malicious Microsoft Office document, but the Agent Exploit Guard feature (which FireEye recommends) can detect the attack when the document is opened.
Proack disagrees with FireEye’s response (e.g., Exploit and Process Guard provided no protection when Mimikatz was used to dump hashes from lsass or when we created a Meterpreter session).
As part of general security hardening and good security practice, the following should be considered:
Disable drive redirection entirely through Group Policy. Computer Configuration\ Administrative Templates\ Windows Components\ Remote Desktop Services\ Remote Desktop Session Host\ Device and Resource Redirection
Setting: Do not allow drive redirection.
Note: Users will lose the ability to redirect their local drives to remote systems while this is enabled; however, they can map network drives as a workaround and still be protected.
Alternatively, call your FireEye representative and demand a fix.
Disclosure timeline:
This vulnerability was reported as per industry best practices:
- November 8, 2019: Contacted FireEye’s general security mailbox providing evidence of the identified vulnerability
- November 8, 2019: FireEye confirmed receipt of our submission and indicated the issue was escalated to the proper people
- November 26, 2019: Follow-up email sent to FireEye requesting an update
- December 2, 2019: FireEye indicated that no fix is available at the moment and their engineering team is still reviewing the submission.
- December 4, 2019: Email received from FireEye suggesting the issue is a misconfiguration with our setup of the HX environment and not with the product itself.
- December 4, 2019: Provided FireEye additional screenshots of our configuration and a video that demonstrated the bug.
- December 5, 2019: FireEye confirms they are able to reproduce the issue, but no resolution provided.
- February 5, 2020: Follow-up email sent to FireEye requesting an update.
- February 5, 2020: Email received from FireEye indicating that the issue will be resolved in their next release scheduled for April 2020.
- February 6, 2020: Emailed FireEye requesting an earlier resolution date, as 90 days had already passed since the initial notification. Offered a 7-day extension for FireEye to provide a fix or workaround/mitigation for their HX customers.
- February 12, 2020: FireEye provides response and mitigation steps customers can take.
- February 28, 2020: Article published by Proack
- October 12, 2020: FireEye issued fix in GA release 32.30.12