It's Me, FireEye!

A little over three years ago, while researching malware execution sandboxes, I found a stealth way to detect FireEye’s Malware Analysis System (MAS). In this blog post I will release the details.

This blog post was originally written in November 24th, 2018. The issue reported in this blog post, as been fixed by FireEye. I'm not able to validate the purported fix since I no longer have access to any FireEye sandbox.

While investigation various Open Source and commercial malware execution sandboxes I developed a tool called Curious Fish (Cufish for short). This tool focused on extracting as much environmental information as possible in order to facilitate the process of fingerprinting these sandboxes.

One such sandbox is FireEye own Malware Protection System (MPS) in its multiple iterations (e.g., Web MPS, Email MPS, etc.) While going through the output of the Cufish tool I found that it made use of a driver called firemon.

Cufish dump showing the existence of the driver.

This looked very interesting and since the details provided by Cufish where quite scarce I used Nosey Fish (Nofish for short, and previously called Infish) to see if I could locate the driver in the file system.

Nofish dump showing the path of the interesting driver.

While the sandbox, at the time, didn’t allow users to download random files / artefacts from the environment, I developed a small utility (Extrovert Fish, Exfish for short) to send the driver file over the network. Chunks of the file are encoded in Base64 and sent over a UDP socket. The only thing left to do was to download the network packet capture from the sandbox and extract the driver from it.

Dump showing part of the base64 driver.

With the driver outside the sandbox, I was able to conclude two things. The first was that accessing (opening and reading) the firemon.sys triggered a malicious activity alert related with sandbox evasion / detection.

If I remember correctly, not fully certain anymore, it wasn't just the YARA rule that detected Exfish tool reading the monitoring driver file.

FireEye MPS report.

The second was that the driver was indeed responsible for monitoring the system for activity (e.g., opening files, deleting files, etc.) as it implements a file system filter driver and injects a DLL in all processes (with some exceptions) using the APC method.

That got me thinking, how could I check if the file existed without triggering such alerts? After some experimentation I decided to give the FindFirstFile Windows API a try. If it didn’t make use of system calls, it would most likely be stealth in such a way the sandbox won’t tag it as malicious.

With this idea in mind, I developed another small utility that did just that. Suffice to say it was successful! The driver could be detected and not a single alert was triggered :D

Disclosure Timeline

2018-11-23: Reported to FireEye

2018-11-26: FireEye acknowledged the report and deployed a content update to fix it. I asked if it was ok to publish the post.

2018-11-27: FireEye's research and engineering team took a closer look into the reported issue and asked for a 90 days grace period to implement additional protections. I extended the grace period 4 days, giving FireEye exaclty 90 days starting from November 27th, instead of the date of first reporting the issue (November 23rd).

2019-01-27: Reminded FireEye that the grace period would be over in a month.

2019-01-30: FireEye will release a version with additional protections for this type of evasion on February, 20th and they're ok with the public release after this date. I will follow the original public release schedule giving extra time for FireEye's customers to update.

2019-02-26: FireEye contacted me letting me know that the customer adoption of the new version has been good so far.

2019-02-27: Released details through this blog post (94 days after reporting it)