VirusTotal is not an Incident Responder

I just want to put it out there first, I love VirusTotal. I use it in both my professional career and in my personal life. When I have been busy and requested by family to investigate some “phishy” email or anything possibly malicious, I have been known to respond with the simple “Have you thrown it up in VirusTotal and seen what it says?”. I am aware that some organizations have used this same check as the starting point for their analysis process. For example, a Defender gets forwarded a phishing email with a link to investigate. The Defender creates the tracking ticket and starts the workflow in their “analysis checklist”. They just want to get through this investigation and close out the ticket. The Defender may not even think about looking at the other things surrounding the email as in whats the content, where did it come from, what are the email headers, and other indicators. The decision to continue or close the investigation has now become all about the outcome of the scan of over 70 AV scanners on VirusTotal. The results (most likely) return that all 70 plus AV scanners claim the link is clean (not one flag). Defender quickly marks all is clear and closes the ticket. In many cases, this might be a quick solution and is not a bad starting point but can provide many false negatives. This post is designed to reveal how VirusTotal is just a tool that aids in analysis and should not be a “one-stop-shop” in determining if content is malicious. Attackers can easily manipulate these results, and I will be going over how one might do so.

This post is designed for both Defenders and fellow Red Teamers. For Defenders, I hope to shed some light on how attackers can manipulate VirusTotal’s URL link scanning to provide clean responses. For Red Teamers, this is just information to add to the toolkit on how to emulate an adversary and challenge Defenders to not make all decisions based on a VirusTotal response.

To make this example more realistic we are going to walk through the analysis of a phishing email (I want it stated, I am not an Analyst/Incident Responder and am sure many have different approaches or better tools, but just deal with it). To find one, I dug into that old high school hotmail email account that I, for some reason, still have but never use. I think the account is now only good for collecting spam and my Fantasy Football reminders. In the Junk Email folder, I found the following email that we are going to investigate.

The email already looks a little phishy and wants the user to click on the “CHECK ACTIVITY” button with an underlying link to hxxp://www.electrogroupintl.com/sallyingif.html . To start the investigation, let’s submit the link to VirusTotal and see the response.

According to VirusTotal the link in the “CHECK ACTIVITY” button is safe and clean. If following our hypothetical example before, we might might be ready to close out the investigation because VirusTotal and the 70 scanners show that the link is safe and clean. But is that really right? Could this possibly be a false negative? Because I am not an analyst and don’t have tickets pilling up, let’s dig in a little more and just focus purely on the link and stay away from the other email features (the content of the email or its headers, etc.).

Using wget , we can download the HTML code for sallyingif.html . The HTML code contains mostly embedded, obfuscated javascript; which already starts giving that sign of something phishy going on here. At a quick glance, the javascript is obfuscated from showing its intended purpose by using random words as variables and functions. Below shows some of the key parts of the javascript.

The javascript code is very interesting, there is a function babyd() that seems to be calling setTimeout() with some parameters. The setTimeout() method calls a function or evaluates an expression after a specified number of milliseconds. So, after 1035 milliseconds, the nighttimec() function is called. Without walking through the analysis of the rest of the javascript (different techniques to do this and I leave that up to the reader if the code is still out there), it is determined that the nighttimec() function call returns the string “window.top.location.href=’http://perfectdeal.su’;” . When combined with the setTimeout() method, a browser waits 1035 milliseconds and then is sent to the url hxxp://perfectdeal.su .

So what we see here is that this site that was scanned by VirusTotal has nothing malicious on it besides JavaScript code that runs in the user’s browser and after a very short time sends the browser to a new link. VirusTotal returns correctly that this site is not malicious as it just redirects the user somewhere else.

Now when the hxxps://perfectdeal.su is submitted to VirusTotal we get a totally different result than the first submitted link. At the time of our scan, the result reports 11 different AV engines that claim the site is a phishing site or is malicious.

The attackers have used the link supplied in the email to serve html and obfuscated javascript code to hide the real malicious site. A Defender who has stopped their investigation after the results of the first VirusTotal scan has fallen into a trap and missed the true nature of the phishing link. This is not some amazing new technique, but something common that I have seen before. In some cases, I have seen multiple JavaScript redirects before reaching the final malicious link.

There was another technique that the attackers were using on the second link that I did not highlight above. The second link ( hxxp://perfectdeal.su ) determined what it served to the requester based on the user agent supplied in the HTTP request. For example, if a request was made with the tool curl with its default user agent ( curl/7.58.0 ), the server responded with an empty reply.

However, if a common browser’s user agent is used, html code for a website is returned. The attacker is trying to filter when to serve up the real malicious page to only users and stop bots, scanning services and other engines from hitting the malicious site.

This is a common attacker technique to serve different content based on user agents, referrer fields, or even IP ranges. This provoked me to think, could you do something similar to VirusTotal and its scanning engines?

Tricking VirusTotal with Apache ModRewrite

I created a quick site, submitted it to VirusTotal and submitted it to be scanned. Watching the traffic that followed, I gathered that there was a VirusTotal UserAgent used after the first submission. I will state that when submitting to VirusTotal there were some other traffic hits on my impromptu website from some other similar services and leave that up to the reader to determine those fingerprints and if those may be related or not to the VirusTotal scanning engine process/work flow.

So we discovered that the attackers were using a technique to trick scanning engines by providing a website with benign HTML code with obfuscated JavaScript code, that when rendered by a browser, would redirect a user to another real malicious site. What other techniques are there that could be similar that might manipulate the results of the VirusTotal scans compared to what a user might access in their browser? Another option, similar to the user-agent filtering above is to use something like Apache’s mod_rewrite to serve different pages to VirusTotal based on the discovered user agent. This way there is something scanned in the results and not just an error page. For an example of an Apache’s mod rewrite .htaccess file used to send different files to VirusTotal see below.

RewriteEngine on
RewriteCond “%{HTTP_USER_AGENT}” “.*virustotal*
RewriteRule “^test.exe$” “safe/clean.exe”

Another option might be to just completely block the perceived IP address of VirusTotal. In limited testing, surprisingly, VirusTotal reported the link clean when the VirusTotal IPs were blocked from hitting an impromptu built website. As I previously stated, there may be other engines and companies that do their own additional scanning some time after a link is submitted to VirusTotal and may provide updates out of band to the VirusTotal report. In these cases, over time a malicious site with some of these different techniques to manipulate VirusTotal may not work with out some diligent previous fingerprinting. I leave that up to the reader to determine the best way to do that.

For the Defender reading this blog, be aware that these techniques occur. Defenders need to think, even though VirusTotal tells me it is clean, “ Does this look right?” “Are there other things that can be done to determine if VirusTotal is providing a false negative?” VirusTotal is a great tool in the toolkit that can provide quick and valuable information. Defenders should consider taking a few more minutes to analyze the contents of the URLs they scan- especially if things look a little, uhm… off . In the email, after pulling down the HTML code of the first link, it was enough for me to know that the site was likely not reputable. Don’t get caught up in the VirusTotal false negative, just because it might be in a checklist.

For Red Teamers, are you using any of the above techniques to challenge Defenders? If you are conducting a phishing campaign, do you use obfuscated javascript or an Apache’s mod_rewrite rule to serve up different files? Personally, while deploying a link that is obfuscated JavaScript which waits and then redirects to another site, I would also at least add additional valid looking HTML code on the page or a “Loading Website…” banner that loads the secondary page after a few seconds. Sure, it still may be phishy, but not as phishy as a line of HTML code with really weird obfuscated embedded JavaScript in it.