Archive for the Packet Tracy Category

The Adventures of Packet Tracy, PI – The Case of the Disappearing Delicacy

Posted in Packet Challenge, Packet Tracy on 15 February, 2013 by Alec Waters


Welcome to my latest challenge, part of the run-up to BSides London 2013. It’s a bit different this time, both in terms of what you have to do and what you get if you do it. The prizes on offer are tickets to the event, with a special prize of a ticket to Hack In Paris for the best entry! Full rules and T’s&C’s are at the end of this post.

Are you sitting comfortably? Then let’s begin…

My name’s Tracy, Packet Tracy. I’m a PI. It says so on my door. Last Tuesday my door was locked because I was out for lunch. Some people only take an hour for lunch, but I do my best work at lunchtime so I take the whole day. As usual I headed for Fat Dex’s Diner on the West Side. Gotta be careful not to confuse it with the oil refinery; the place is covered in a film of grease, and Fat Dex ain’t called Fat Dex for nothing.

I slid in through the front door, tripping over tumbleweeds left and right. I had my choice of tables – the last time this joint was full Kennedy was on the throne and Fat Dex was just called Dex. Even so, lately there are so many tumbleweeds I worry they’re planning some kind of global uprising. Better stock up on weedkiller.

Wendy comes over with something she claims is coffee, but I suspect it’s actually come from the refinery. I ask her for my usual zeppelins in a fog, but when she brings them over it looks like they’ve come from Lakehurst field instead of the kitchen. Oh the humanity.

I can hear Dex crashing about out back. Clearly something is rotten in the state of Dexmark, which is usually my cue to leave before Dex and the Knuckleduster Twins politely ask me to pay my tab. In between tripping over tumbleweeds and slipping on grease he manages to get the jump on me and we sit down for a gentlemanly discussion. He looks stressed and he’s sweating. More than usual. Which is a lot.

Dex says takings are down and the Fatelli brothers are on his back and unless he turns things around soon they’ll be breaking it. He says it’s not his fault, but it never is. According to Dex only San Andreas has faults.

This time he might be right. Some new joint called Iggy’s Eats has opened up on the East Side, and Dex can’t compete. He says they’ve got more money than he has grease, and they’ve got a brand new three-storey R&D facility that’s kicking out some kind of seafood dish that people come from miles around to hook. If that wasn’t bad enough he says they’ve stolen his secret recipe for cheese on toast. 

Before I can tell him that particular recipe ain’t so secret, he says he’s got proof that’ll send Iggy and her Eats down the river to Sing Sing quicker than you can play a song song. Wendy’s culinary talents are below par because she’s tired – she’s been on a nocturnal special op on behalf of Dex. She got close to Iggy’s top guy Jamie and was able to go through his drawers once she was done going through his drawers. She came back with a USB stick with Dex’s stolen cheese on toast recipe on it, enough proof to get Iggy a private room in the State’s finest long-term accommodation facility. But there’s a problem that’s stickier than Dex’s tables – the recipe’s encrypted. According to Wendy the password is in a safe in Iggy’s private office, and not even a team of invisible ninjas is getting in there.

So that’s what Dex is after – he needs me to decrypt the stick and get the proof that Iggy has stolen his recipe. It was a tough case, but you don’t call a PI for the easy ones…

For all you budding PIs out there, the question we need answered is very simple. The crime of corporate espionage has been committed, but who stole the recipe and who will end up in the dock? Iggy? Jamie? Someone else? You’ll need to conduct a thorough investigation and write up your evidence so PT can take it all to the Judge. When you’re done, you can submit it via email here.

Before we give you the USB stick, please take a moment to read the rules:

  1. You cannot enter if you are a volunteer for this event or a member of the BSidesLondon crew
  2. You must submit your answer by April 1st 2013 18:00 (6pm) GMT
  3. The first three people to submit the correct answer showing all the steps taken to determine the guilty party will get a ticket to BSidesLondon13
  4. After the closing deadline the best answer will get a ticket for Hack In Paris 2013, a ticket to BSidesLondon13 (if required) plus a further winner of BSidesLondon13 tickets will be selected from all those who have submitted a correct and complete answer. These winners will be decided on criteria including the thoroughness and completeness of the presented investigation, and/or the use of an appropriate narrative style
  5. Judge’s decision is final and prizes can’t be exchanged for cash or favours 😉
  6. This challenge will involve you interacting with live systems via the Internet. If the system’s name doesn’t end in, you’re in the wrong place and you should stop.
  7. The only tool you need to dish up the dirt is your brain – step away from the BackTrack laptop and use GreyMatter 1.0 instead. Any forceful attempts to “hack” the challenge systems may result in it being taken offline prematurely, which would be a shame. All necessary information is provided for you – all you need to do is find it!
  8. For data protection purposes, names and email addresses of participants will only be used for the challenge, and will be shared with the challenge creator only for the purpose of selecting the best answers. You have Packet Tracy’s cast-iron no-spam guarantee!
  9. All characters, organisations and other such entities featured in the challenge are fictitious. Any resemblance to real persons, living or dead, is purely coincidental.
  10. Play nice and have fun, and please don’t share any answers with anyone!

Ready? You can download the USB stick image here.

If you need any hints, you can try asking PT himself, but he’s pretty tight-lipped, especially in public!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at

The Adventures of Packet Tracy, PI

Posted in NSM, Packet Tracy, Sguil on 14 May, 2012 by Alec Waters

My name’s Tracy, Packet Tracy. I’m a PI. It says so on my door. Last Monday morning began like every other with a fumble through the fog of a hangover looking for new and unexplained bruising. The pounding in my head was aided and abetted by the pounding on my door, and aspirin couldn’t fix both. I dragged myself towards the noise and let in a dame wearing stilletos and a scowl that could shatter concrete at fifty paces. She said her rat of a boyfriend had been flirting with some internet floozy, and all the proof was in the pcap on the USB stick that left another bruise after bouncing off my head. No problem, I said, come back Friday for chapter and verse.

The case was tougher than I thought; the pcap was bigger than my last bar tab and there’s no way I want to go over that line by line either. So I ran it past my Bro and a couple buddies of mine, Suri and Carter, but none of us could come up with the dirt. The dame’s been on my back all week for results, and now it’s Sunday and the pounding is back with a vengeance. She’s at the door, calling me names I’m pretty sure my mother never gave me. I considered leaving by the window until I remembered my office is in a basement and there aren’t any.

Time’s up. Gotta face the music… 

So how come PT couldn’t come up with the goods? The evidence was there, surely it was just a matter of time before he found it?

I’m sure a good many of us have been in needle-in-a-haystack situations where we’ve had to rely on some tool or other to process a gigantic pcap. If the tool doesn’t find what we’re looking for, either it’s not there to find or the analyst or tool itself wasn’t up to the job.

So are all tools created equal? Given the same pcap and the same task, will they return the same results?

I thought I’d run a number of URL extraction tools against a standard 128MB pcap, the kind you might find on a Security Onion box, and I set up a quick deathmatch cage fight between httpry, urlsnarf, Suricata, tshark and Bro. All versions are the ones shipped with SO, and the config files haven’t been tweaked in any way from standard.

I realise that this is hardly a thorough and scholarly test, but I think that the results show a point worth making.

The tools were invoked like this:

user@sensor:~/httpexperiment$ httpry -o httpry.log -r capture.pcap
httpry version 0.1.6 -- HTTP logging and information retrieval tool
Copyright (c) 2005-2011 Jason Bittel <>
Writing output to file: httpry.log
5230 http packets parsed

user@sensor:~/httpexperiment$ urlsnarf -n -p capture.pcap > urlsnarf.log
urlsnarf: using capture.pcap [tcp port 80 or port 8080 or port 3128]

user@sensor:~/httpexperiment$ suricata -c /etc/nsm/sensor-bond0/suricata.yaml -r capture.pcap
<tons of output>
4/4/2012 -- 15:35:58 - <Info> - HTTP logger logged 2206 requests

user@sensor:~/httpexperiment$ tshark -r capture.pcap -R http.request -T fields -e frame.time -e ip.src -e ip.dst -e tcp.srcport -e tcp.dstport -e http.request.method -e -e http.request.uri -e http.request.version > tshark.log

user@sensor:~/httpexperiment$ bro -r capture.pcap

Now, we need to process httpry’s output a little, since it includes server responses as well as client requests. Once done, we can see how many HTTP requests were seen by each tool. The results were a little surprising to begin with:

httpry: 2567 requests seen
tshark: 2557 requests seen
Bro: 2240 requests seen
Suricata: 2206 requests seen
urlsnarf: 2198 requests seen

httpry and urlsnarf are often (probably quite rightly) viewed as less sophisticated than Suricata and Bro, and tshark might not be the tool of choice for this kind of work, especially when you’re constantly monitoring traffic on an interface rather than processing a pcap. Bro and Suricata certainly picked up things that httpry didn’t (HTTP on non-standard ports, for example), but there’s quite a gulf between the apparently less-sophisticated and the cutting-edge.

So why? Each tool does the job in a different way, and with its own set of pros and cons. httpry, for example, only listens on ports 80 and 8080 by default, has no support for VLAN-tagged frames, and performs no TCP session reassembly so it is vulnerable to evasion. On the other hand, the more sophisticated Bro and Suricata have, to my knowledge, no such shortcomings.

However, it’s httpry’s brute simplicity that I suspect put it on top of the pile for this particular test. All it looks for is one of a nominated set of HTTP method verbs at the beginning of a TCP segment. It doesn’t care about proper TCP session establishment or teardown, all it’s looking for are a few bytes in the proper place. In contrast, other tools may not log any URLs at all if the TCP session isn’t complete and well-formed.

Each tool’s results were a subset of the others’ collective results – no one tool captured the superset, and one could probably achieve “better” (or at very least, “different”) results by tweaking each tool. Even then I reckon there would still be a pretty good chance that there are undiscovered URLs lying there that a different tool could pick up.

I don’t mean for this to be seen as some kind of ranking of tools, or a statement that httpry and tshark are “better” URL extractors than Bro and Suricata; all I’m trying to say is that you’re almost certain to miss something by only using a single tool for a job like this. On the flip side of course, running two or more URL extractors might seem like a galactic waste of resources…

Your mileage will almost certainly vary, but it’s worth keeping this in mind when the dame is at the door demanding answers!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at