Paul Asadoorian: Hello everyone and welcome to Offensive Countermeasures – Making Attackers’ Lives Miserable. My name is Paul Asadoorian, I’m from PaulDotCom, and this is John Strand, also from PaulDotCom and the SANS Institute.
So, just a little brief information about the background of this talk. John and I do a lot of penetration testing: companies hire us to test the security of their organizations. We found that over time we were amazingly successful, and it wasn’t because we’re the best penetration testers in the world necessarily, but because the defensive measures we found in place were inadequate for the measures we were using to break into those organizations.
So, one day we sat back and thought: “What can we do better? What better recommendations can we make to our customers? What tools can we arm people with to better defend their networks?” Hence this talk was born, which talks about the three different areas we’re going to talk about, what we call offensive countermeasures. And that’s taking a little bit of a splash of offense, and applying it to defense. Some people will call this hacking back, and when I say that phrase, people usually look at me with shock and horror: it’s ok, don’t panic, we’re going to go over all of the different aspects of it. So, John, if you want to maybe introduce some of the concepts on this slide, including annoyance, attribution and attack.
John Strand: Great, absolutely. So, when we were working through offensive countermeasures, as Paul mentioned, we started with the definition of insanity for Albert Einstein. Definition of insanity is doing the exact same thing over and over again, expecting different results. And if you look at computer security, the vast majority of what we’ve been doing and selling: antivirus, IDS, IPS – it’s doing the same thing over and over again. So when we tried to come up with new approaches for trying to make an attacker’s life miserable, we broke it into three sections:
Annoyance. What can you do to just make an attacker incredibly annoyed with your network security architecture? What can we do for attribution to actually identify who it is that’s attacking our network? And also, what can we do for attack? Now, before people start freaking out yet again with the idea of hacking back, a lot of what we’re going to talk about are going to be things that are easy to implement and we don’t have to worry too much about legalities; but there are going to be some legalities that we are going to talk about a little bit later, surrounding offensive countermeasures.So, with the legalities: pretend for a second that I’m a lawyer. Anything that you do in this area for offensive countermeasures, we strongly recommend that you discuss, document and plan it. One of the things that is interesting about this area is: there’s not a lot of research, there’s not a lot of case law, so if something does go wrong and the attorneys do get involved and judges get involved, if they saw that you did due diligence to actually document it, came up with a plan and have reasoning – it looks a lot better than trying to shred the documents in the process of doing it. So, trying to hide your intentions basically says that what you’re doing you know is in fact wrong, and the court will take it as such. Rule of thumb is: don’t be evil. We’re going to talk more about what being evil to an attacker would actually be like. Paul Asadoorian: So, annoyance. Some people will say: “Why would you want to annoy an attacker?” And the best reason that I give them is that when you do things like annoying an attacker, it tends to slow them down, it tends to let them give up some information about themselves, which leads you to be able to detect their presence inside of your network. So, putting up a little script that maybe causes their tools to do something funky – that may be an event that you can track and may lead to you discovering that attack just by putting some things inside of your network that are meant to be an annoyance to your attacker. John Strand: So, here’s one of those annoyances, one little script that we came up with (see image). We did the same idea on Windows as we did for Linux as well. Once again, the idea is to try and get the attacker to slow down, get the attacker to make more moves so you can detect them.
So, this little script, which is distributed with our slides here at RSA, you can set up a little listener on port 3333. If you look at the slides, you’re going to see 3333. We have Netcat listening on that port, you can have anything listening on that port. If anybody makes a full established connection to that port, and this is why it’s so important, a full established connection: the attacker sends a SYN, you send back a SYN-ACK, they send back an ACK – that is established. As soon as that established session is created, it’s going to add a firewall rule.
As you can see, it says: “do netsh advfirewall firewall add”, we give it a name – Whiskey Tango Foxtrot; direction in, remote IP address is a variable, the IP address that’s connecting in; local port – any; protocol TCP – block.
Now, the reason why this is critical, some people would say: “You can’t do this, because all the attacker has to do is spoof their source address.” This will not work, it’s very easy to spoof source addresses for things like SYN packets; but it’s incredibly difficult to spoof an entire established connection; although not impossible. It is very difficult to do.
Paul Asadoorian: One thing along with the HoneyPort: make sure the port that you choose is a port that you know should never ever be used in your environment, so monitor your environment, know which applications are happening, and for the most part choose a port that you know: if you see activity on this port, it’s because of your HoneyPort and because of nothing else.John Strand: Absolutely. And this one is one that we have for Linux (see image). It does the exact same thing we covered on a Windows slide previous, but this one’s listening on port 2222. We actually had one of our customers implement this; they had a thousand Linux servers. Pentesting company showed up, ran a port scan, the initial SYN scan saw servers with all kinds of ports open. As soon as they did more invasive testing, like a vulnerability assessment scanner or doing full-connect scans with Nmap, the entire network went dark. Now, when you’re pentesting and the entire network just disappears, you tend to get a little bit nervous that you may have crashed the entire network. It took the pentesting company about half a day to figure out exactly what was going on.