Raising Costs for Your Attackers Instead of Your CFO

Abstract

Signature based detection is no longer an effective means of detecting and blocking modern malware. Whitelisting is a much more effective way of preventing malicious code from executing. Many organizations already own tools to implement whitelisting so the only cost is time and effort to properly implement these tools. While it is not perfect, if implemented correctly it can vastly reduce an organization's attack surface allowing defenders to focus on more advanced threats rather than common malware. It can also force attackers to utilize expensive exploits to gain remote code execution and add difficulty for attackers in maintaining persistence.

Content

Recent high profile breaches have proven time and time again that the methods we are using to protect our computers and networks simply aren’t adequate. Defenders rely too heavily on outdated signature based detection mechanisms allowing attackers to use "simple" techniques to bypass their defenses. The 2013 Verizon DBIR noted that "78% of initial intrusions rated as low difficultly." [p. 6]

Signature based detection simply can’t keep up with attackers ability to modify their code to avoid detection. Packers and encoders make it easy and inexpensive for an attacker to generate more than 10,000 unique files per hour making signature based detection useless in defending against the threat.[p. 6] Because most end users have the ability to execute any file they can download all an attacker has to do is trick someone into running their new executable via social engineering.

Whitelisting is the opposite approach. Instead of identifying and detecting malicious software, known good software is identified and only that software is allowed to execute. Unfortunately whitelisting hasn’t caught on. Many feel that it is cumbersome to work with or expensive. In reality, the level of effort needed to implement and maintain a whitelisting system is likely less than what is needed to respond to infections and it can be accomplished using tools that most organizations already own.

AppLocker is an example of classic application whitelisting technology which is built in to the enterprise and ultimate editions of Windows 7, 8, and 8.1 as well as Server 2008r2, 2012, and 2012r2. AppLocker allows an administrator to define which executable files will be allowed to run using either local policies or domain Group Policy Objects.

While AppLocker can be used to whitelist every file on a computer individually, a more reasonable approach is to use AppLocker to start by whitelisting file paths which only administrators can write then limit who has administrator rights on the computer through Group Policy Preferences. Administrators can then install known good software to these locations without needing to whitelist individual files and regular end users without administrator rights will not be able to execute arbitrarily downloaded files. When editing AppLocker rules there is an option within the AppLocker GUI to create “default rules” for these Program Files and Windows directories.

Implementing AppLocker in this manner is extremely effective in blocking common malware. The recent Cryptolocker ransomware is often distributed in zip files containing a malicious executable. When the EXE file is run it installs itself within the user profile before executing to encrypt the user’s files.[p. 1] Remote Access Trojans generated by advanced attackers often use the same tactics. The Mandiant APT1 report shows a very similar attack.[p. 28] The attackers use this tactic because often it works. Deploying default AppLocker can stop both attacks.

AppLocker is not a perfect whitelisting solution. It only applies to EXE files, MSI files, and certain types of scripts. Interpreters are one way to get around AppLocker limitations. AutoIt, Java, Flash, Python, etc are all ways that an attacker could potentially execute code if they are installed on a computer. Macros and other scripting functions within applications can also be used.[p. 1] An attacker could also use native tools that are installed with Windows by default such as PowerShell. This risk can be minimized by creating exceptions for the default rules to exclude system utilities regular users will not normally need and create AppLocker rules that explicitly deny unwanted applications or interpreters.

Another approach to whitelisting is to limit which applications have the ability to access network resources. A malicious dropper file or Remote Access Trojan is far less useful to an attacker if it is not allowed to access the internet. Application aware “Next Generation Firewalls” are one way that you could potentially limit what applications have network access. However, they are expensive and can be potentially subverted by tunneling inside of what appears to be legitimate traffic.

A client side firewall configured with tight egress filtering is a more economical approach. Because client firewalls are intimately aware of the application that is requesting network access, the same approach used by AppLocker to generally allow any applications installed in Program Files or Windows directories can be used to allow executables in these directories to talk to the network and deny anything else. This will prevent files downloaded to the user’s profile from being able to do any further damage. Cryptolocker for example will not actually encrypt any files until it has exchanged keys with its command and control server.[p. 1]

Both AppLocker and client firewalls will require some care to allow specific applications that only run from the user profile. Net meeting software such as Webex will need to have specific rules created to allow its use. However, this upkeep is less cumbersome than remediating infections.

Application reputation is a third approach to whitelisting. Most enterprise endpoint protections suites include some sort of reputation based detection which blocks files that are not well known or signed by reputable software makers. The tactics used to evade classic signature based anti-virus will normally cause the file to be detected based on low reputation. Depending on the solution organizations may be able to set different thresholds for different computers. For example, servers or high value workstations could receive more strict policies than standard end user computers. Microsoft implemented a version of this through its SmartScreen filter in Internet Explorer 9 which examined downloads through IE. SmartScreen has been expanded to apply to all downloads in Windows 8.[p. 1] Reputation based detection can block execution or delete files that don’t have good reputation, regardless of path. It is worth noting that all reputation based systems rely on some sort of cloud service and thus leak some metadata about what is being run.[p. 1]

By implementing whitelisting, defenders can force attackers to use exploitation to gain remote code execution. If the defenders have done a reasonable job of patching their systems the attacker may need to resort to developing an exploit or buying one on the black market which is far more costly than simply packing or encoding “off the shelf” malware and asking someone to run it. Whitelisting is most effective when deployed in a fully enforced mode. However, if enforcement is not achievable, all organizations should consider implementing these technologies in an audit only mode so they can have a better chance of detecting malicious behavior.

References

Metadata

Tags: whitelisting, AppLocker, firewall, reputation, antivirus, malware, trojan, Windows

Primary Author: Aaron Beuhring Primary Author Bio: Aaron is an Information Technology professional with over 12 years experience in computer support, systems administration, computer forensics and computer security.

Previous“How I Met Your Mother” or The Brief and Secret History of Bletchley Park and How They Invented CrypNextThe “Science of Cyber” and the Next Generation of Security Tools

Last updated