The economics of malicious software is separated into multiple facets:: mass malware distribution and targeted malware.
Mass malware distribution depends on a network of services – groups delivering hacked websites and compromised hosts for file storage, groups bearing compromised advertising networks, and groups providing services to make the malware undetectable.
For the criminals, having compromised legitimate websites (at a certain point, even Forbes.com was compromised for several months, delivering targeted malware) means that your automatic malicious URL blacklisting systems would not work, and they will be able to pass through your defenses easily.
Access to compromised (or just willing to deliver anything for the right price) advertising networks means criminals can pay malicious software on virtually any website – including Youtube, for example (there have been multiple occurrences of the same).
Combined, the two above create an unprecedented threat environment where any website can deliver a malicious payload to your users – when even whitelisting, believed to be a draconian measure, would not help much.
Moving on to MAAS – or Malware As A Service
Malware as a service delivers on two promises – at any point, your adversaries will have access to compromised hosts and undetectable malware. If a certain number of vendors start detecting the malicious sample, their fully automated service will generate a new model and deliver it where needed – no interaction required.
When a compromised host or website gets on any blacklist, the malicious code automatically moves to a new set of compromised hosts. This is part of their SLA (service level agreement) – and as mature business people, they are well aware of the reliability they need to maintain to retain their customers in a highly competitive underground market.
Their model is solid and proven – and relies on return on investment like any other business model. To disrupt their operations against your business, you could do only one thing: raise the costs of attacking you using their automated methods so that the attacks become unprofitable. At this point, they will move to another target.
That is IF you are not explicitly targeted – at which point it will be only a matter of time until the actual compromise occurs – where your incident response and digital forensics capabilities will be tested, but that is a discussion for an entirely different chapter.
Preventing Exploit Execution
If you followed through on the previous chapters and have implemented app locker/software restriction policies and a commercial product to control the execution of unknown applications/code, if you have complete control over PowerShell and have blocked malvertising to the maximum possible extent – it is time to move on with prevention of exploit execution.
There are commercial and accessible solutions for this purpose, but you have to be extra careful when testing and evaluating them, as what is advertised is not always what is in the box.
Years ago, a well-known name in the AV industry sent a project for evaluation – and they had a point where their ‘unique anti-exploit functionality’ had to be tested. They promised protection from a specific RDP exploit. So I tried the exploit, and lo and beheld, the defense was working! I was surprised, but digging deeper, it turned out all the product did was use the Firewall to block RDP connections from outside. Turn off the firewall functionality and the exploit crashed the system completely. Exploit prevention? Always test and ask tough questions before spending considerable money on software licenses. Ultimately, not even the money spent is at risk – it is the protection of your assets (or lack thereof).
Malwarebytes Anti-exploit (https://www.malwarebytes.org/antiexploit/) is one product I recommend you try and compare to its free counterparts.
When evaluating a security company, I always suggest looking for signs of non-commercial community work. For example, they release helpful, non-marketing targeted tools to help users fix their information security problems. Malwarebytes excels in this field – if you look at their free tools section, you might find plenty of good ones – https://www.malwarebytes.org/downloads/#tools.
EMET
The operating systems widely deployed at the endpoints are vulnerable. God forbid you’re still using Windows XP – but I’ve seen even the Space and Naval Warfare Systems Command of the USA visit my website from an XP box, so I guess everything is possible.
Even Windows 7 is outdated by modern standards – but migrating to a newer operating system is not always possible for multiple reasons, especially in larger environments.
3rd party software is also rarely updated, primarily due to a lack of knowledge and experience on the side of IT staff – they don’t see the reasons or don’t know how to update to the latest PDF reader or Flash version (but why even have Flash on the endpoints, is another question), they don’t patch the installed office applications with their latest security patches unless forced specifically by an audit requirement or finding.
For at least three years, there has been a ‘silver bullet,’ guarding against application vulnerabilities and preventing exploitation by adding a second layer of defense between the operating system kernel and the applications on Windows systems. The name of this silver bullet is EMET (Enhanced Mitigation Experience Toolkit). At the time of this writing, the latest version is 5.2 – a very mature application, I would say.
I am constantly amazed by how many IT “experts” have not heard of or are not using EMET. Given its effectiveness and price – FREE – and given its developer – Microsoft – with the sole purpose of protecting Microsoft Windows operating systems from exploitation, ly is challenging to comprehend why people ignore this product.
This is likely one of your best and most effective defenses against exploits – even when they are attacking non-updated plugins like Flash, Java, and Silverlight. And let’s be honest, does your company auto-update all plugins to their latest versions as soon as one is available? Sadly this is almost always not the case.
For those of you who are not familiar with the concept, you can get yourself acquainted on the following links:
http://support.microsoft.com/kb/2458544
https://technet.microsoft.com/en-us/security/jj653751
http://blogs.technet.com/b/srd/archive/2014/07/30/announcing-emet-v5.aspx
http://support.microsoft.com/kb/2909257
Please, break the rule and read the manual! After that, go ahead and download and install the tool. The installation page will offer you to download the manual as well – do it and read it. It’s not the best manual out there, but that is why my book exists!
Let’s get into the technical details.
The settings you see on this screenshot are not the default – they are recommended (by Microsoft and me). On the first launch, click the dropdown menu and choose “Maximum security settings,” then reboot your computer.
Note: some AV products might interfere with EMET. If that is the case, you can contact them, ask for support, uninstall them, and get a better AV product. In all cases – EMET should be preferred over an antivirus product anytime. After all, if you follow the advice in this book, you will never need to rely primarily on antivirus for your security again!
Most people don’t even get to this point – they install EMET and consider their job done – and it’s not. Next, click Import, go to C: Program Files (x86)EMET 5.1DeploymentProtection Profiles, and import Popular Software.xml. You can also import the other two XML files, but this one is the most important.
This step will add configuration settings for widely used applications to prevent nagging crashes and issues of incompatibility.
If you encounter application compatibility issues – namely, some apps crashing and the EMET window popping up saying it has blocked something – or if you see events in the event log that emet has closed an application due to some mitigation – you have two options: either it has been a legitimate threat (exploit), or you have encountered a bug in the application. Sometimes these conditions are caused by a very long uptime when EMET confuses memory addresses used by apps and thinks it’s an exploit. Sometimes these crashes are caused by a conflict with other security software. Sometimes you need to update the crashing application, and sometimes… you need to re-configure EMET.
Here is how to do it.
Go to the main screen, then click on the Apps icon:
You will see the following window:
Usually, the event log will tell you which mitigation has been triggered – most often, it is Caller Mitigation. If this happens to you, you could turn off this specific mitigation for this particular application – fully aware that you are losing a part of your security. Never disable mitigation settings unless you are sure this cannot be rectified by updating your application, OS, EMET, or AV.
There have been blog posts about certain security consultancy firms bypassing EMET – I can assure you these were written primarily for marketing purposes. It is still not common for attackers to use exploits capable of bypassing EMET, and it is still advisable to implement it in your company as soon as possible.
If you think about it, everything can be bypassed – does that mean that if a protection measure can be avoided, you should not install it?
Other malware prevention measures
I wish NIST 800-83, http://csrc.nist.gov/publications/nistpubs/800-83/SP800-83.pdf – Guide to Malware Incident Prevention and Handling,” was made mandatory for implementation everywhere.
My recommendations on this document: there are action items that you can mark (with a colored marker) for implementation and add to a project, something similar to “Malware prevention measures” – then add all the action items on a timeline and task the IT / IT Security teams for their implementation.
Simply reading will yield little benefit as the document is a bit high level, not getting into many technical details, which I think is on purpose. Otherwise, they would have to go down to the vendor-level configuration settings, which is not the document’s purpose.
Other server/workstation hardening ideas
I recommend getting rid of any binary that is not essential to the business operation of a workstation or server.
Deleting non-essential binaries
Does a specific user need cmd.exe, reg.exe, regedit.exe, cscript.exe, at.exe, psexec.exe, nbtstat.exe, ftp.exe, bitsadmin.exe, makecab.exe, quser.exe, ieexec.exe, schtasks.exe, netstat.exe, sc.exe, xcopy.exe, nslookup.exe, taskkill.exe, tasklist.exe, route.exe, regsvr32.exe, ping.exe, wmic.exe, powershell.exe?
There are several ways of dealing with the situation.
- Delete the binaries when needed – bring them with you to the machine
- Restrict execution with a policy
- Rename them – cmd.exe could become dmc.exe, for example (after appropriately tweaking the system’s self-preservation mechanisms to return such system files to their original form). Renaming renders many automated attack scripts/exploits / etc. useless., just as well as deleting or restricting with a policy.
The same applies to any operating system.
Please use proper change management, testing, and implementation for all such changes – some systems management software uses PowerShell, and some enterprise scripts might need a script to run – take this advice with a grain of salt and always test for an extended period before rolling out such drastic hardening measures across the enterprise. Rendering a system unusable is worse than not implementing a hardening measure.
More on PowerShell:
A security expert (Nikhil Samrat Ashok) recently posted a set of posts on his blog named “Week of PowerShell Shells.” If you’re unfamiliar with what a shell is in this context, it is a way to obtain a remote ‘command line shell’ via non-standard techniques, such as sending and receiving ICMP (Ping) packets.
So while you’re sitting there and looking at your clean traffic showing only ping packets traveling between systems A and B, someone might have a complete remote control.
Well, it would be best just to read the blog posts to get a better picture:
http://www.labofapenetrationtester.com/2015/05/week-of-powershell-shells-day-5.html
http://www.labofapenetrationtester.com/2015/05/week-of-powershell-shells-day-4.html
http://www.labofapenetrationtester.com/2015/05/week-of-powershell-shells-day-3.html
http://www.labofapenetrationtester.com/2015/05/week-of-powershell-shells-day-2.html
http://www.labofapenetrationtester.com/2015/05/week-of-powershell-shells-day-1.html
The above blog posts prove just one thing – if PowerShell is available on a system, it represents almost everything an attacker needs to utilize the system and penetrate deeper into your network.
It is yet another reason to lock it down and make it accessible only to administrators and only on specific machines, not on all your endpoints.
The following two posts by Microsoft will help you lock down your PowerShell:
“PowerShell’s Security Guiding Principles” – http://blogs.msdn.com/b/powershell/archive/2008/09/30/powershell-s-security-guiding-principles.aspx and “PowerShell Security Best Practices” – http://blogs.msdn.com/b/powershell/archive/2013/12/16/powershell-security-best-practices.aspx
