Securing the Digital World

The Realm of Threat Intelligence - It's all about the Packets, or is it?

Sep 13, 2016 | by David Gray |

Full Packet Capture (FPC), those three little words are enough to make most security analyst salivate at the prospect of finding and detecting attacks. Back in the days before anyone realized that you could build an Intrusion Prevention System to actually stop attacks, the Intrusion Detection System was king. If you were very lucky you had the support to build a Linux/Unix server running TCP dump. Life as an Analyst was good, all you had to worry about was what was happening on the wire and once you found an attack it was somebody else's problem to resolve. We have surely moved on a bit from those days.

Whilst detection systems have become more advanced and integration of security systems has become a key selling point for many vendors, FPC is still enough to make any security analyst get sweaty palms. There are many other security tools that give you an overall threat picture including RSA's own Archer and NetWitness Platforms, some vendors pull in only log sources (SIEM's) which most analysts had forgotten to check for years! Packets are where it's at - everything that passes the sensor on the wire is recorded and can be analysed immediately or later (depending upon your storage space). The FPV has been the TIVO of the security world (and who doesn't like TIVO?) However these days it is all about the full picture of logging with SIEM's and Threat Intelligence.

There are not that many times that a security analyst can conduct an investigation from one source of information and categorically give a confirmation of a true or false positive status. In most events (logs) the analyst has to pull in a number of corroborating facts before an event can be confirmed, and in many serious cases a full host forensic examination is required. Not so packets. If the traffic you are analyzing is on the inside of your network and you have confirmed it to be malicious, you are going to have a busy day! That said, you have a copy of the malicious traffic and can create custom signatures to identify the scope of the issue and block it. In the case of files you also have the hash value and can search your network for other identical threats. This is of course assuming you know how to read packets and therein lies the first chink in the armor.

Packet Analysis is not easy! Sure you can fire up Wireshark and if you already know the traffic you are looking for it is relatively simple to isolate a stream and extract it for analysis, but if you don't then a lot of deep analysis is required. This is the first major issue. Any SOC that is running any kind of FPC requires a highly trained workforce, which is an expensive resource and is hard to find these days. Secondly and probably the greatest issue is you are recording ALL of the traffic. Which is good right? Ask your Lawyers. This issue is especially difficult for multinational organizations which have to comply with rigorous privacy laws: an example of this is Germany which has one of the strictest privacy laws in the World. In this sort of situation it is unlikely that a Full Packet Capture solution will be deployable without a serious number of constraints on the mission statement and the analysts' taskings.

Those issues notwithstanding Packet Analysis is a key skill for any SOC analyst. With a well-staffed and motivated team, attackers will face a hard time compromising a network without facing rapid detection. APT (Advanced Persistent Threat) has been both a major threat to Government Organisations and Companies alike and formed a part of any security vendors' sales guide. If you are serious about detecting APT or any other advanced threats to your network packets are the most effective way of identifying what has happened. Yes, your SIEM may alert on unusual IDS traffic or logons to a server/host remotely with elevated privileges, now what? Packets give you the granularity to identify exactly what has happened, how the attack occurred, what was exfiltrated, protocols used. If the attack is still ongoing you can even go as far as monitoring the command and control (C2) traffic to see what commands the attacker is issuing and decide at what point to take remediation actions to resolve the breach.

An example of just how packet analysis (and network signatures) can be used to detect attacks would be to look at PoisonIvy. PoisonIvy is one of the most famous (infamous) of Remote Access Tools (RAT's) which has been used in many APT attacks across all verticals. PoisonIvy begins with 256 bytes of seemingly random data once it has completed its TCP handshake this information coupled with its most common ports 80, 443 and 8080 (as well as its default port of 3460) can give a good initial detection capability. This can be strengthened if the rule logic also contains the 4 bytes sent by the controller specifying the size of the machine code it will send. Over the versions of PoisonIvy seen this has consistently been "D0 15 00 00". This is just one example, however it shows how analysis of a threat coupled with the known network indicators can give a good detection capability. Time to start writing some content rules!

There is one other huge benefit which is really only available to organisations with a large enough budget or a Government Organisation; storing multiple months' worth of network traffic and replaying them with the very latest IDS/IPS signature set. As your SOC team has already dealt with the traffic in real time the signature set can be created from ONLY the vulnerabilities and zero days which have become public after compromises have taken place. Replaying the traffic in this way enables organisations to go back in time with modern detection methods and detect previously unknown attacks and remediate effectively.

Finally when you take the logs from the IDS/IPS and review them in correlation with other network logs you have a very strong set of defensive measures.

You monitor your logs...right?