Tuesday, September 13, 2016

Hello World

One of the tasks I get to perform at work is to research and study malware and try to find ways to mitigate it and minimize the damage it can do. I am tasked with assessing our defenses and where necessary providing additional layers for my organization to block malicious activities from occurring on workstations or servers without getting in the way of legitimate work.

I have been in several organizations where pen testers had already demonstrated that they could send attachments or get people to click on links to executable files that would bypass traditional defenses such as IPS, email filtering, URL filtering, sandboxing, and anti-virus. After that they were a command away from downloading .exe, .js, .dll, .reg or a host of other persistence mechanisms and free to do their work through covert C2 channels. Malware that was being blasted to us through spam campaigns or delivered through exploit kits was behaving similarly.

I have worked on traditional defense mechanisms for several years. I have a networking background and have spent a considerable amount of time trying to win this battle from the network infrastructure side, but find myself frequently bumping up against the limitations around trying to write policies that can effectively block this kind of activity. Don't get me wrong, I believe that IPS and firewalls and URL filters and such are an important defense mechanism and can effectively block many of the off-the-shelf attacks. But if something is targeted or just happens to fall within the range of addresses that I had to allow out from my workstations I frequently found myself unable to write a policy that was granular enough to stop it. Firewall/IPS/Proxy vendors have been working to fix this but they haven't cured the problem yet. There is a lot of malicious activity that is simply well behaved at the network layer. On top of that, things like custom encryption, new ciphers, or psychedelic obfuscation was limiting the effectiveness of the policies I did have and even updates several times a day weren't fast enough to keep up with the latest attacks.

Over time I have realized that winning the security battle is going to have to take place in large part on the endpoints. Managing a worm outbreak in my environment exposed me to the power of endpoint enforced policies. For a while only allowing pre-defined applications to run proved to be a big help and I became convinced that this would be one of the most effective ways of preventing this malicious activity. The next big thing for me was anti-exploit, and I dove into tools like Microsoft EMET. These are all still very effective, but the adoption of PowerShell by malicious actors flies right through many of the mitigations I had in place, and folks like Casey Smith are finding all sorts of ways to skirt around the limitations of these technologies.

My purpose with this blog is to explore different mitigations that I find (if any) to address these issues. I like to share my work (where I can) with the intent of helping the blue team and making contributions back to the security industry. Sometimes my thoughts will be partial or a work in progress. Sometimes it will just be lamenting how a mitigation didn't work. Sometimes they will just be about random things that seem cool at the time. Maybe the purpose will grow or change over time. Hopefully I can keep it coherent and the blue team finds it useful.

-Branden
@limpidweb

No comments:

Post a Comment