Whenever I am on an engagement that involves the analysis of network traffic, my preferred tool of choice is the RSA NetWitness Network (Packets) solution. This provides full packet capture and allows for analysts to "go back to the video tape" to see what happened on the wire. When the decoder examines the traffic, it tries to identify the service type associated with it. HTTP, DNS, SSL and many others are some examples. However, there are times when there is no defined service. This results in 'service = 0'.
When time allows, I like to go in there, but as you may notice, there can be quite a lot of data to go through. Therefore, I like to focus on small slices of time and attributes about those sessions that makes sense. For example, I might choose the following query over the last 3 hours.
service = 0 && ip.proto = 6 && direction = 'outbound' && tcpflags = 'syn' && tcpflags = 'ack' && tcpflags = 'psh'
This query will get to the sessions where:
service = 0 [OTHER traffic not associated with a service type]
ip.proto = 6 [TCP traffic]
direction = 'outbound' [traffic that starts internally and destined for public IP space]
tcpflags = [Focus on SYN, ACK, and PSH because those TCP flags would have to be present for the starting of a session and the sending of data]
Next, I look at associated TCP ports (tcp.srcport and tcp.dstport) as well as some IP's and org.dst meta. What we recently found was a pipe delimited medical record in clear text. After some additional research, we came across this fantastic blog post from Tripwire discussing Health Level 7 (HL7). In it, the author, Dallas Haselhorst, even showed the pipe delimited format that the HL7 protocol uses to transfer this data. It was this format that was observed on the wire.
While the idea of medical records being transmitted on the wire in clear text was alarming at first, it was determined that this was in fact, a standard practice. If used to cross the Internet, VPN tunnels would be used.
To get a sense of how much traffic I could see, I created a parser to identify this as 'service = 6046'. I chose '6046' because that was the first port I observed, however in truth, we eventually saw it on numerous tcp.dstport's. This parser is just going to identify this as HL7 and will not parse out the information contained in the fields. Some of that data will likely contain Personal Health Information and it is not something I wanted as meta. But, knowing it is on the wire in the clear was important to me and my client.
If you work in an organization that handles this kind of data, this parser might help identify and validate where it's going.
Good luck, and happy hunting. Also..special thanks to one of my new team-mates, Jeremy Warren, who helped find this traffic.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.