Monday, February 29, 2016

"Eradicating Zero Day Malware?" / A Discussion of Terminology and Some Best Practices

Hey everyone - Someone asked me an interesting question, and I thought it was worth a little bit of discussion in a post.  The question was "Once you discover zero day malware, how do you get rid of it?"  Let's talk about it after the jump.

Malware Versus Exploit

Before we get into it, I want to make a note about two terms that are often used interchangeably that probably should not be: malware and exploit.  Exploits can be classed as malware, but not all malware can be classed as an exploit.  An exploit is a very specific piece of software, hardware, or activity that takes advantage of a vulnerability in a system.  When you think of an exploit, you might think that it always has to be a piece of software.  This is not always true.  When social engineering, for example, your charisma could be your exploit to take advantage of a gullible person.  Most of the time though, an exploit refers to software code.

Malware is any piece of software that is delivered onto a system with hostile intent.  It could be an exploit or a remote administration tool (like meterpreter, a tool that comes with the Metasploit framework and allows you to interact with a machine).  Legitimate software can also be made into something malicious.  See this blog post for more about malware and its use of legitimate software.

"Zero Day"

Zero day typically refers to an exploit, and it means an exploit for which is there is no known patch.

So I think what the person wanted to know is if you discover that you are a victim of malware, what should you do?  These steps are useful regardless if there is a patch available or not.  The thing to remember is that until a patch is released, you can only mitigate a zero day exploit.  Mitigation can take many forms depending on the nature of and attack vector used by the malware.

Do Not Panic

The first thing to do is to relax and resist the urge to set all of your systems on fire in an effort to get rid of the malware.  Overreacting will lead to missed details and the possibility of destroying evidence which might be useful in finding the malware elsewhere in your organization or for criminal prosecution if it comes to that.  Exploits are typically a delivery vector for something else (usually malware).  Most exploits take advantage of the way a program deals with something it did not expect, like strange input or a condition it did not expect.  That can cause the exploited program to run in strange ways which might leave key indicators behind.  Indicators include:
  • Errors in system logs.  On Windows, these will be available in the Event Viewer.  On Linux, the logs may be in /var/log or in the journal (viewable using journalctl) if the system uses systemd.
  • Pop-up windows on systems with a GUI.  If you see a pop-up saying an application has stopped working or something similar, that could be an indicator that something is not right on your system.
These are things you would find after the fact.  It would be tough to see exploits happen in real time unless you have a host-based IDS or similar tool running on your hosts and exporting logs to a central place where someone is monitoring them.

Even if the exploit does not leave a trace, the malware that is deployed afterwards likely will.  You might be able to find traces of that by looking in process lists, loaded libraries, network connections, and open files.  All of these traces we have talked about so far, from exploits, malware or whatever are often referred to as indicators of compromise, or IOCs.

Even if the exploit is new, the malware might not be, so if you find something suspicious, it might be worth searching for it to see if anyone else has seen anything like it.

Anything that got onto your system had to come from somewhere: either put there by an insider or with the unwitting help of someone in your organization via a phishing e-mail.  That means you can work backwards to figure out how it got there, and you can work forwards by using the knowledge of what the malware or exploit looks like to see if it is anywhere else in your organization.

Working Backwards

In order to reconstruct how the malware got into your network, you need logs or some "smoking gun" like an e-mail that someone clicked on or a USB drive that someone brought in that was infected from home.  Logs to look at include system logs as we talked about above, IDS logs at the the system or network level, and logs for any services that are exposed to the outside world if you think the malware and exploit may have come from the outside.  If you think it may have come from the inside, check audit logs on your authentication servers (like Domain Controllers) looking for things like strange login times and multiple failed attempts to authenticate.  Be aware that these things could mean that an outside person is masquerading as someone in your organization, so keep an open mind when performing any sort of investigation.

If you are keeping backups, you may be able to get an idea of when the malware was introduced or when the exploit occurred.  If your backup from last week did not contain the malware or some other IOC, then you can limit the time period you need to investigate.  Likewise, if your users started complaining about abnormal behavior on their systems in the past week, that helps you narrow down the time period you need to look at.

If logs are not available, you can still take steps to make yourself a more difficult target in the future.

Working Forwards

This is not an exhaustive discussion of steps you can take to mitigate the risk of becoming the victim of malware or an exploit.  A more tailored plan depends on your situation: budget, network layout, goals, resources to maintain the security measures, et cetera.  However, these things are general steps you can take which should help.

In addition to getting rid of the files, you need to make sure it is harder for the attacker to get back in.  This means that any weak configuration needs to be shored up.  For example, if you have a dictionary word for the password to your router, it would be best to change it.  If you do not patch the hole that the attacker used to get in, then they can get in again.  If the exploit they used has no known patch, you will need to do the best you can so that even if they do get a foothold in your network, they will not get far.  Ideally, they will have to work hard, and hopefully make mistakes along the way so that you can catch them before they can steal too much of your information or do any damage in your network.

Reduce Your Attack Surface

If there is a service installed somewhere in your network that you are not using, get rid of it.  This does not mean disable it from starting automatically.  Uninstall it completely.  For example, if you have just finished migrating your Flash-based applications to HTML5, then you should remove Flash from your machines because it is a popular attack vector.  To do this effectively, take stock of what you need your servers and workstations to do and remove anything that you are not using.  Sometimes it is not possible to completely remove something if it is part of the OS, but there are typically steps you can take to block it from doing anything or at least disable it.  One example of this is Microsoft Edge on Windows 10.  It is part of the OS, so you cannot remove it, but there are ways you can stop it from being able to run.  A word of warning though: be careful when messing with anything that is integral to the OS.  It can cause unintended side effects.  So do it in a VM first and observe what happens.

Audit Privileges In Your Organization / Separation of Roles

We have talked about this in the past, but one thing to make sure of is that the privileges granted to the people in your organization match what they do in the organization.  For example, people in the Accounting department might not need access to everything in the Engineering department.  You can use file system permissions and access controls (see this blog post) to enforce the roles that are already defined in your organization.  Doing this is a good idea because this can help isolate data in case your network is compromised.  In our example, if someone in the accounting department is infected with malware that wipes out Office files, that malware will likely run as that user.  If all users in the Accounting group do not have permissions to access files in the Engineering folder, the malware will not be able to get to them from that user.  While that does not help accounting (hopefully those files were backed up in a place the malware could not get to), it helps contain the effects of the malware.

Another good practice is to give your network and system administrators separate administration accounts from their normal user accounts.  If an administrator falls victim to malware on his normal account, it will be harder for the malware to wreak havoc throughout the network.  When the administrator needs to administer things, he or she can use their administrator account for those tasks and those alone.  That will definitely help keep things separated.

Stay Patched

You probably hear this a lot, but one important thing you can do to protect yourself is to stay up to date on patches.  This includes software besides your operating system.  Many programs check for updates periodically, so it is important to apply these updates as soon as you can.  In a large organization, it would be wise to test updates on a non-critical system.

Integrate Network Defense Where Possible

If you have the resources, an important step you can take is to deploy defense measures that sit in your network or on your hosts and report on anything 'strange.'  These intrusion detection systems react based on rules defined by you or rules that come with the software.   It would be best to tailor these rules to the needs of your organization.  An IPS takes it a step further by taking action on the 'strange' things it sees.  These Intrusion Prevention Systems take action such as closing network connections it sees as 'bad' or stopping processes that are doing 'bad' things if the IPS is on a host monitoring its activities.

When you are thinking about deploying these kinds of measures, it is important to remember that these tools are not 'set it and forget it' kinds of tools.  They require upkeep and maintenance (keeping the software and rules up to date, having someone monitor and react to the alerts, and tweak the rules as conditions change).

In terms of network defense, you might want to block any IPs or domains that the malware appears to be communicating with.  That is fine, but it is a losing battle.  Malware can change the servers it can talk to after it is deployed, so you might be playing a cat and mouse game.  So do not stop with blocking the communication: follow it up with eradicating the malware (preferably by re-imaging the boxes to a known good backup).  This could mean more than simply deleting the files depending on how the malware is structured.  It could utilize a program that works in the background to make sure the malware is in tact, and if it is not, to regenerate it.  Getting rid of a specific type of malware depends on that malware, so the steps will vary.

Host-based Solutions

In addition to traditional network and host-based IDS and IPS solutions, there are more specialized solutions that help prevent attacks from specific types of attack vectors.  We will talk about two for Windows and two for Linux.  I hope to cover these a bit more in future posts.


  • EMET - The Enhanced Mitigation Experience Toolkit (or EMET) is an application that protects applications against common exploit techniques.  While there are ways to bypass its protections, it makes it harder for an attacker to pull off a successful exploit.  In order for an attacker to be successful when all of EMET's protections are enabled, the attacker would have to get around all of the protections at the same time which is not trivial.
  • AppLocker - AppLocker allows an administrator (or home computer user with a Pro or higher version of Windows) to write policies that determine which applications are allowed to run.  For example, if you only want signed applications to run, you can have an AppLocker policy to enforce that.  Any application that is not signed would not be allowed to run.


  • SELinux - Security Enhanced Linux (SELinux) is a set of Linux kernel modifications that allow for the implementation of mandatory access controls.  We talked about mandatory access control last week in our discussion of permissions.  Through the use of policies, SELinux allows granular control to system resources.  If an application tries to access memory it should not be accessing, SELinux can deny the application.  It is installed an enabled by default on Red Hat derivative versions of Linux (such as Fedora, CentOS, and Red Hat Enterprise Linux), but it is available for other distributions as well.
  • AppArmor - AppArmor is similar to SELinux, but it enforces rules based on file paths instead of file system attributes.  The real difference is in administration.  AppArmor tries to make administering it relatively easy.  It is installed and enabled by default on Ubuntu and SuSE-based distributions.

User Education, Trust, and Awareness

An often overlooked component of a strong information security program is including users in the process.  An attentive user can be like a sensor for your IDS.  If they know what a phishing e-mail looks like or something else that looks suspicious, they can report it.  That means two things: your users need to know what to look for (and not to click on it) and they need a mechanism for reporting.  It is important that your users have a way of reporting security issues they encounter on your network.  Additionally, they have to know that they will not be punished for reporting security issues.  If a user thinks he or she will get in trouble for reporting something because suspicion or ridicule is waiting for them, they will keep quiet.  That is not what you want.

Final Thoughts

We have introduced some best practices when it comes to defending your information and reacting to malware (but definitely not all of them!).  What constitutes best practices for your organization depends on your organization and its needs, resources, and risk tolerance.  The way to start is to take an inventory of what you have, what you want to protect, and the resources you have to protect it.  Then, you can develop a plan around that.

What are your thoughts on recovering from malware?  Do you have any war stories?

Thanks for reading! 

No comments:

Post a Comment