The economics of malicious software separate into multiple facets, two of which are mass malware distribution and targeted malware.
Mass malware distribution depends on a network of services itself – groups delivering hacked websites and compromised hosts for file storage, groups delivering compromised advertising networks and groups providing services to make 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.
Having access to compromised (or just willing to deliver anything for the right price) advertising networks means criminals can deliver 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 in time 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 sample and deliver it where needed – no interaction needed.
As soon as 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 in order to retain their customers in a highly competitive underground market.
Their model is solid and proven – and relies on return on investment just as any other business model. In order to disrupt their operations against your business, you could do only one thing: raise their costs of attacking you using their automated methods so much as for the attacks to become unprofitable – at this point they will move to another target.
That is IF you are not targeted specifically – 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 put to the test, but that is a discussion for an entirely different chapter.
Preventing Exploit Execution
If you followed through on the previous chapters and have implemented applocker/software restriction policies and / or a commercial product to control the execution of unknown applications / code, if you have full 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 free 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 tested the exploit and lo and behold, the protection 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 a considerable amount of money on software licenses. In the end, not even the money spent is at risk – it is the protection of your assets (or lack of the same).
Malwarebytes Anti-exploit (https://www.malwarebytes.org/antiexploit/) is one product I would recommend you to try out and compare to its free counterparts.
One suggestion I always give when evaluating a security company: look for signs of non-commercial community work. For example, releasing useful, non-marketing targeted tools designed to actually help users to 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.
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 due to multiple reasons, especially in larger environments.
3rd party software is also rarely updated, mostly due to 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.
Since at least 3 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 to protect Microsoft Windows operating systems from exploitation, it really is difficult 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:
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 the recommended ones (by me and by Microsoft). On first launch, just 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 and ask for support or 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 an antivirus for your security, ever again!
Most people don’t even get to this point – they install EMET and consider their job done – and it’s not. Next, you need to click on 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 most important.
This step will add additional configuration settings for widely used applications which will 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 kind of 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 just 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 happened to you, you can turn off this specific mitigation for this specific application – fully aware that you are losing a part of your security. Never disable mitigation settings unless you are absolutely 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 that you 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 bypassed, 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 which you can mark (with a colored marker) for implementation and add these 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 much technical details, which I think is on purpose, as otherwise they would have to go down to the vendor level configuration settings, which is not the purpose of the document.
Other server / workstation hardening ideas
I generally recommend getting rid of any binary which is not essential to the business operation of a workstation or a 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 the proper tweaking of the system’s self-preservation mechanisms trying to return such system files to their original form). Renaming renders useless many automated attack scripts / exploits / etc, 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, some enterprise scripts might need cscript to run – take this advice with a grain of salt and always test for an extended period of time 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 SamratAshok) recently posted a set of posts on his blog, named “Week of PowerShell Shells”. If you’re not familiar with what a shell is in this context – it is a way to obtain a remote ‘command line shell’ via non-standard techniques, for example by sending and receiving ICMP (Ping) packets.
So while you’re sitting there and looking at your clean traffic showing only ping packets traveling between system A and system B, someone might actually be having full remote control of said systems.
Well, it would be best to just read the blog posts to get a better picture:
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 to administrators only and only on specific machines, definitely not on all your endpoints.
The following 2 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