The Role of Network Forensics in Major Network Breaches

It’s unfortunate, and very disturbing, that major network breaches continue to top the news. While Target digs in and works to identify the exact attack signature and all its nuances, Neiman Marcus and Michael’s now join the list of retailers recently suffering from significant data breaches. And these breaches differ significantly from those common just a few years ago, when hackers were content with changing a website home page with a “look what I can do” mentality. Today’s breaches are highly targeted, low profile, and designed purely for the economic gain of those implementing the attack. In other words, Grand Theft Network.

Let’s just take a brief look at what’s been made public so far about the Target breach to get a better understanding of the threats facing enterprise IT teams:

  • It Was Long
    By Target’s own admission in their website notification to customers[i], card purchases between 11/27 and 12/15 were vulnerable, a 17-day window. And that assumes the initial breach occurred the instant that customer data became vulnerable, which we know is not the case. So this threat went undetected for more than 17 days. Unfortunately, that’s shorter than the industry average. Verizon’s 2013 Data Breach Investigations Report[ii] found that 66% of breaches took months or longer to discover. So, perhaps Target hasn’t done a bad job so far – just an insufficient one.
  • It Was Targeted
    No pun intended. Yes, it was targeted at Target. Maybe they should seriously consider changing the bull’s eye logo? I digress. How do we know it was targeted? Well, we don’t know exactly how, but according to an online article in KrebsonSecurity[iii], an undisclosed source close to the Target investigation was quoted as saying “They [the malware] were customized to avoid detection and for use in specific environments”. And given the length of time it took to identify the breach this certainly makes sense.
  • It Was Widespread
    The key component in the breach was a PoS (point of sale) malware program, which was designed to record all data from credit and debit cards swiped through the infected system. Target has not disclosed how many PoS machines were compromised, but given that up to 110 million customer credit cards were stolen it seems safe to assume that the PoS malware was very widely distributed.
  • It Was Reasonably Sophisticated
    The PoS malware was only one component of the breach, although a very important one. The perpetrators had to first break into the Target network, and KrebsonSecurity indicates this was done by compromising a Target web server. The PoS malware then was distributed to the PoS machines, and it’s still unknown (or undisclosed) exactly how that was accomplished. A control server was then set up within Target’s internal network that was the central repository for all of the stolen credit card data from the PoS machines.The attack was then carried out in two phases. According to post on Seculert, “First, the malware that infected Target’s checkout counters (PoS) extracted credit numbers and sensitive personal details. Then, after staying undetected for 6 days, the malware started transmitting the stolen data to an external FTP server, using another infected machine within the Target network.”[iv] This is certainly a characteristic of an advanced threat.
  • It Used Techniques We Already Knew About
    According to KrebsonSecurity, the “[PoS] malware has been used in previous intrusions dating back to at least June 2013”. But the fact that it made it undetected, along with any other hacking tools used, by the 40+ commercial enterprise antivirus toolsiii again speaks to the targeted, sophisticated nature of this attack.

That’s what’s been made public so far. When it comes to breaches like this, two primary questions come to mind.

  1. How does the victim figure out what happened?
  2. How does the victim, and others, prevent similar attacks from happening again?

In this blog, let’s focus on the first question – how was Target able to compile the above data (and certainly much more that has not been made public) to determine the scope of the problem and the fingerprint of the attack?

As with any crime, investigators comb the crime scene and look for clues – forensics – and in this case, since the clues are primarily computer related, they use network forensics. And also as with any crime, the better and more prevalent the clues the quicker the crime is solved.

What is network forensics?
Network forensics is the capture, storage, and analysis of network events. Network events include any and all activity on the network, from initial access to data transfers to application usage. These events can be captured and stored in various ways, but the three most common sources of historical network data are logs, flow-based reporting, and packet capture and recording. Each data source has varying degrees of details, with log data being the lightest on details and packet data being the most complete. The ability to store this data for long periods of time is of course inversely proportional to the level of detail of the data.

Network forensics from logs and flow-based data
We don’t know what type of data Target has available for its forensics analysis, but at a minimum they are sure to have at least some log information since just about every asset on the network generates logs, and most enterprises have solutions in place to store and subsequently mine log data over relatively long periods of time.

While undoubtedly useful, logging has several shortcomings when relied upon for network forensics. First, log data only provides reports of relatively high-level events, such as users logging in and out of boxes, and cannot tell you how something happened, only that it did. Second, logging has to be enabled. You can be sure that the control server that the perpetrators set up as part of the Target breach was not sending log data, so at the log level there will be no useful clues from one of the key elements of the investigation. Finally, logs can be altered, since log data is typically just text. So although log data can provide some level of network forensics, it is not very deep and it is subject to alteration, making it an unreliable source for network forensics.

Flow-based reporting typically provides overall network performance information, like utilization on network links, top talkers, top applications, etc. The reporting granularity is usually one minute, but to save space as data ages the granularity often gets reduced by time averaging data together, so after a month the data may only have 1 hour granularity. Quite a bit can happen in an hour – can you imagine trying to perform network forensics when you only have one hour granularity? It’s like using a vacuum cleaner instead of a pair of tweezers to collect clues at a crime scene.

Packet-based network forensics
When it comes to true network forensics, the best source is packet-level data. By recording each and every packet traversing the network you have the most complete, and most detailed, data available. Packet-level forensics provides a complete recording of ALL network activity, down to each and every bit that gets transmitted and communicated on a network. This includes payload information as well, so you can see exactly what is leaving your network and where it is going. Packet-level recording is quite demanding from a storage perspective, so you may not have the capacity to store weeks worth or packets, but with a packet-based network forensics solution in place you will at least have the last few days, and probably more, recorded.

And with packet-based analysis you can set up monitors and alerts to always be looking for suspicious behavior. In the case of the Target breach, having a packet capture looking only for FTP activity at the WAN link would have triggered an alert for each FTP session that was initiated. This is a small and manageable data set which could easily be reviewed by IT staff, since most organizations will not have a tremendous amount of FTP traffic. From our perspective any FTP activity is at least a little suspicious, so it should be analyzed. And if you have known processes that do perform routine FTP transfers you can always filter these out so only the FTP transactions you’re not expecting are flagged by the alert.

Since we don’t have all the facts on the Target breach, and probably never will, we cannot say for sure that a packet-based network forensics solution could have seen suspicious FTP traffic earlier in the timeline, but it’s certainly a possibility. And even if a packet-based network forensics solution did not trigger any specific suspicious behavior, once the breach was recognized the solution would provide you with a recording of many days of network activity, making the task of determining the fingerprint of the attack, the depth of the penetration, and the data that was compromised much easier to assess.

Don’t wait for it to happen to you. Learn more about the benefits of packet-based network forensics at http://www.wildpackets.com/use_cases/network_forensics.


Leave a Reply