Timeline
- Reported to FireEye on May 7th
- FireEye confirmed receipt of the vulnerability disclosure and stated that it was already a known issue being prioritized for a future release
- FireEye EX releases update to remediate this issue on August 13th
Inspect What You Expect
Organizations spend heavily on security tool suites designed to detect, block, and generate alerts for malicious activity. From email filtering to endpoint detection, these tools are relied upon by organizations to prevent attacks at all steps in the kill chain. Someone registers a domain name with your company’s name (perfect for phishing). Does anyone notice? An email using the phishing domain has a malicious attachment or link. Does it get blocked? The user downloads the malicious attachment and executes it. Does your endpoint detection and response (EDR) tool prevent it from executing? An attacker establishes a command and control (C2) channel on a workstation and exfiltrates data. Is the C2 communication detected? It is critical for organizations to validate that tools within the security suite are operating as expected, else they remain juicy targets despite a large security budget. These tools and the environments in which they are placed are complicated. This makes it necessary to create a runbook of test cases and ensure, at each step in the kill chain, that security tools are operating as expected.
One approach for this is to perform Purple Team exercises. That’s where red and blue teams come together to coordinate testing and assess what attacks are blocked, what is detected, and what alerts are triggered.
Not What We Expected
When performing purple team engagements, one of the common campaigns is a simulated spear phishing attack. Companies often rely on secure mail gateways, such as Agari, FireEye EX, Proofpoint, Mimecast, to inspect and determine if malicious links and attachments are present in the email. In this case, I was testing against FireEye EX, which makes a request to the linked file in a sandboxed environment and performs analysis on the file contents. FireEye EX successfully blocked standard artifacts generated by tool sets such as Cobalt Strike, Metasploit and Empire.
Each email sent in the campaign was quarantined after the links were visited by the FireEye sandbox.
The Homograph Attack and the Ḍirty Screen Attack
One particularly effective way to fool users into clicking on links is by registering a domain which is very similar to a trusted domain. Most people know that, for instance, a capital I looks the same as a lowercase l. An attacker who registers a domain like this can send phishing emails with links which appear trusted.
Internationalized Domain Names opened a new way to send link malicious links. Using a homograph attack, the user may take advantage of Unicode characters, such as a Cyrillic A, which look identical to a Latin A. This type of attack has been discussed in various places already.
When performing the simulated spear phishing attack, FireEye EX had no problem blocking emails with links leveraging the homograph attack.
As a variant to the homograph attack, there are also Latin characters with a dot below them, which I refer to as dirty characters. For instance, ‘ḥ’ is a lowercase h with a dot below, and it looks just like there is some dirt on the monitor below a regular ‘h’ character.
FireEye EX Failed to Parse Links with Ḍirty Characters
In a few test cases within the spear phishing campaign, I registered an attacker domain using one of these dirty ‘ḥ’ characters. I was still using standard payloads at this point, but for some reason the emails were making it straight through to the user’s inbox without being flagged by FireEye EX.
We noticed something interesting when examining the EX console. Typically, FireEye detects links within emails and performs analysis on the linked content. In this case, the link that FireEye detected was not the same link provided in the email. When the parser gets to the dirty character, this is treated as the end of the link – meaning that FireEye had no way to inspect and determine the link was malicious.
Examining the logs on the web server, I noticed that FireEye was not making the expected calls from the sandbox server to inspect the malicious links – not even the incorrectly parsed link. With this knowledge in mind, an attacker can successfully send any malicious link without being detected simply by registering a domain with a character that the FireEye parser fails on.