The New Security Fundamentals – Kill Your AV

John Strand //

AV is Dead

Long Live Whitelisting. We have been discovering more and more of our tests bypass AV controls with ease.  We have yet to see any iteration or vendor in the blacklist space who is adequately preventing attacks using simple blacklist solutions.  What needs to be done in this industry is a move towards a whitelisting approach.  This can either be in the form of a product like Bit9, Lumension or Bromium.  Or, it can be in the form of using existing controls such as Applocker and/or Software Restriction Policies (SRP).  We recommend organizations start with Applocker then work their way up to full Application Whitelisting.  

Basically, you can start by defining exactly what directories are allowed to run various programs.  For example, we can lock down programs to run from the Windows and Program Files directories.  There are ways to bypass this (i.e. ISR-Evilgrade style attacks, exploit the app and launch from that directory), however, the overall improvement to the security of an environment is extensive.  

To put it bluntly, if I had to choose Applocker or traditional AV, I would choose Applocker every time.  Further, this is not something that is product-specific. It is something you probably already have in your environment.  This is key as it does not require purchasing another very expensive tool to achieve.  

Firewall Everything  

Another key trait we see in many successful organizations is the heavy use of internal firewalls.  While we have gotten pretty good at setting up firewalls on the parameter of our environments, we are still horrible at enabling the things on the inside of our parameters.    Now, let me be crystal clear on this.  The built-in firewall on Windows is horrible.  Its login is hideous and it can be a pain to enable across your environment via group policy.  

Turn it on anyway.  

There is also the option of using the firewalls built into various AV products.  The nice thing about these firewalls is that they are already deployed and can be managed from a centralized location.  From a policy perspective, these should be set up on the workstations that can only be accessed from tightly controlled Admin VPNs and server subnets, but the workstations cannot talk to each other. At all.  There is no good reason to have workstations talking to each other over SMB.  Users should not be sharing files in this way.  

Ever.  

Basically, you want to treat your internal network as hostile, because it is.  

What does this do?  For starters, it will stop an attacker from pivoting using pass-the-hash attacks or token impersonation to other workstations.  I cannot stress this enough: When we are testing, we pivot from machine to machine till we find one with a local privilege escalation vulnerability or has sensitive data we can access.  But turning on your local firewall, you can effectively stop this from happening.  

Attackers can still access file servers and critical services.  But, those communication paths are known and can be monitored far easier than trying to monitor every communication between every system.  

Internet Whitelisting

This is, by far, the most contentious item in this write-up.  Any time I talk about Internet whitelisting in a class or at a conference, I get a lot of screaming, crying, hiding under tables and breakout sessions of alcoholism.

Yeah, my presentations can get out of hand quickly. But before all the pitchforks and Molotov cocktails get thrown in my general direction, I want everyone to take a deep cleansing breath.  See, when I discuss Internet whitelisting, people have this odd vision of Internet star chambers convening to debate, in painful detail, the pros and cons of every website their users request to access.  Blood will be spilled…  Joints pulled from sockets.  

That is not what I am talking about.  Rather, let’s play a simple mental game.  Let’s say hypothetically, that you whitelist the top 1,000 sites on the internet. Of course, you would exclude porn, gambling, and One Direction sites.  But, you would allow all others.  Then, if a user wanted to access a site, not on the list, you would do a quick review, then allow it.  No blood, no inquisition. Heck, you could even allow users to automatically add sites.  

Would your total exposure to the Internet be more or less than it is now?  

The answer is it would be dramatically reduced.  Not even a small fraction of what it was before.  Yes, the sites you allow could possibly be used to attack your users.  But, if your users were compromised, the resulting C2 would most likely not go through.   Remember, the goal is not reducing risk to 0, but rather trying to get it to an acceptable level.  Also, this will further reduce the white noise that often needs to be cut through in almost any incident or Hunt Teaming engagement.  

Discrepancy Analysis  

At any security team’s core, the goal should be simply to identify deviations from the norm.  However, as an inverse to this, it also requires us to have a firm understanding of what exactly “normal” is.  This is both harder and easier than many people believe.  For example, trying to take an inventory of every system can be a total nightmare. However, there are tools out there that can be of assistance.  First, the Security Onion has Bro installed and it has a very cool ability to do a full inventory of all the user-agent strings that pass through it.  This can be used to quickly identify user-agent strings which are abnormal.  Why does this matter?  First, it can be very helpful to identify old systems that are still lurking in your environment.  If all your systems are Windows 7-10 and you see a Windows XP user-agent string, then it could be a UA string for a piece of malware, or it could be a very out-of-date system that needs to be eradicated like a termite or roach.  

Some other tools that are outstanding for discrepancy analysis are Kansa and Microsoft Advanced Threat analytics.  Both of these can be used to baseline large numbers of systems and run comparisons of the configurations, applications and network connections (Kansa), or the user behavior on the network (Microsoft Advanced Threat Analytics).  

Conclusions  

Years ago I made a joke.  I said environments would be far more secure if they would simply remove anti-virus.  I made a few people mad.  My point is this: if we did disable AV we would be more secure.  Looking back, I should have been far firmer with my analysis.  

YOU WOULD BE MORE SECURE!!

Why?  Because then you would do all of these other things to secure your network.

AV/IDS/IPS are all security theater.  They provide an illusion of security that was never there.  We need to get beyond them.  We need to understand that attackers will bypass them (because they will) and then start building our networks accordingly.