How to catch hackers security sensors don’t see – Part 2
In case you missed it, Part 1 is here.
Let’s say a hacker has managed to establish a presence on your network through some means – email, malicious Website, direct compromise or unknowingly by a user or system administrator. If your host and network intrusion detection system, anti-malware or logging system doesn’t alert someone that something is amiss, you’re in big trouble. If the hacker is able to communicate out of your network without being detected, the situation has gone from bad to worse. But if this is the case, how will you ever know that a hacker is on your network?
If your ability to detect compromise is reliant upon alerts from commercial and freely available security software, then you are at a serious disadvantage against a sophisticated attacker. While you definitely need to use alert-based products, you need to start using other tools that are not reliant on alerts. What you need, is a tool that allows you to analyze network activity to find a hacker’s covert network communications. This is the key to finding hackers your security sensors don’t see.
The type of convert network communications I’m talking about uses well-known ports, is RFC compliant and properly balances uploads and downloads. It’s easy to catch someone that is using an unusual protocol or port number, and there are lots of products that can detect non-RFC compliant protocol usage. There are even simple network statistics tools that can be used to help identify uploads or downloads that are indicative of a compromise. What you need, is an analytical tool set that utilizes data from a full packet capture system, which allows you to manage, manipulate and view data in whatever ways you see fit. And where do you find such a tool? You need to build it yourself. Ethereal, WireShark and other packet capture software allows you to capture and analyze packets, but they won’t help you with the type of analysis I’m talking about.
I’m going to end this post with a scenario for you to think about:
A desktop Trojan uses the HTTP protocol over TCP port 80 utilizing standard GET requests. Appended to the end of each URL is an encrypted string that is actually part of a system’s password file, which was broken into small chunks and encrypted. The hacker’s server is running a custom version of some blogging software that parses the URL and recreates the password file on the distant end. The hacker’s server returns actual articles from the site that the user never sees and packet inspection reflects actual articles posted on the site. The Trojan only communicates when it sees the user start-up a browser. The Trojan uses URLs that look something like the URL below.
If you didn’t know what this activity looked like, how would you find this activity in a network of 200 users?