Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog - Whitelists: The Holy Grail of Attackers InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Whitelists: The Holy Grail of Attackers

Published: 2017-04-05
Last Updated: 2017-04-05 06:22:04 UTC
by Xavier Mertens (Version: 1)
4 comment(s)

As a defender, take the time to put yourself in the place of a bad guy for a few minutes. You’re writing some malicious code and you need to download payloads from the Internet or hide your code on a website. Once your malicious code spread in the wild, it will be quickly captured by honeypots, IDS, ... (name your best tool) and analysed automatically of manually by the good guys. Their goal of this is to extract a behavioural analysis of the code and generate indicators (IOC’s) which will help to detect it. Once IOC's extracted, its just a question of time, they are shared very quickly.

In more and more environments, IOC’s are used as a blacklist system and security tools can block access to resources based on the IP addresses, domains, file hashes, etc). But all security control implements also “whitelist” systems to prevent (as much as possible) false positives. Indeed, if a system drops connections to a popular website for the users of an organization or other computers, the damages could be important (sometimes up to a loss of revenue). As a real life example, one of my customers implemented automatic blacklisting based on IOC’s but whitelists are in place. To reduce the false positives, two whitelists are implemented for URL filtering:

  • The top-1000 of the Alexa[1] ranking list is automatically whitelisted
  • Top URL's are extracted from the previous week proxy logs and added to the list

To remain below the radar or to bypass controls, the Holy Grail of bad guys is to abuse those whitelists. The Cerber ransomware is a good example. It uses URL's ending with "/search.php". They are used to download the malicious PE file:

Once the malware analysed, the URI "/search.php" became quickly an interesting IOC. Check some occurrences from my MISP instance:

By choosing a generic URL like this one, malware writers hope that it will be hidden in the traffic. But when it becomes blacklisted, there are side impacts. I had the case with a customer this week. They had to remove "/search.php" from the list of IOC’s because their IDS was generating way too many alerts. Other examples that I already met with similar URLs:

/log.php
/asset.php
/content.php
/list.php
/profile.php
/report.php
/register.php
/login.php
/rss.php

Another approach is to compromise a website categorised as “clean” and flagged in a nice web category. Here is a good example of a website for kids but hosting malicious content:

If typosquatting is still used (ex: use "ro0tshell.be" instead of "rootshell.be"), it’s more efficient if you can host your malicious content behind a real domain with a nice score in lists such as Alexa. And often, the site itself don't need to be compromised. The victim DNS can be hacked / poisoned and new records added to those “nice” domains. The victim session can be hijacked using MitM techniques. The whitelist will do the rest...

[1] http://www.alexa.com/topsites

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key

4 comment(s)
Diary Archives