Unsung tools - Raptor Forensics

Every so often you come across tools that get very little press. One such tool in my humble opinion is Raptor Forensics bootable CD from the fine folks at Forward Discovery. In short, this cd needs to be in your toolkit if it isn't already.

One of the most popular questions I see is "How do I acquire a macbook air?". While I'll try to address that question specifically, I want to widen the scope because it applies to any mac system that need to be imaged.

When dealing with a macbook air your options are somewhat limited.

• There's no firewire
• There's no network card (unless you use the usb port)

What's an investigator to do?

Well obviously if the box is on you can use F-response to acquire it rather quickly. You can only do this however if you have the proper credentials.

What if you're going in clandestinely? What if the system is handed to you and it's off? This is where Raptor Forensics bootable CD comes in.

Burn the iso
Attach a powered USB hub to the macbook air.
Attach a USB target drive formatted however you see fit(though you can do this within Raptor).
Attach a USB cd drive.
Insert the cd.
Boot the mac while holding down 'c'.
The environment will boot.



After the system boots click on the Raptor Toolbox. When it opens you'll see the following.



This is where my biggest problem with tool originates. The workflow from left to right is all out of whack. In order to acquire an image, you need to mount the target drive. In order to mount the target drive it needs to be formatted. In order to be formatted it should be wiped. Now, you've probably already done this but in my opinion, and in terms of workflow in this toolkit it should be changed.

That said, let's format and mount a target drive. First, click the 'format' tab.



Next, Click the 'mount' tab and select your target device. You'll want it to be read/write.


Great! Now that it's formatted and mounted let's acquire something!

In this case I'm imaging a USB key, but it works just fine for the macbook air and other macs. Since everything is point and click it's a pretty straight forward process. Just select the source, target, name and make sure you select 'verify' and then Start.


An imaging window will appear as well as a verification window (which looks the same) when the time comes.

Once acquisition and verification complete you'll see a nice log window appear that shows the acquisition command line and hashes.


And it's just that simple. Hopefully this helps those in need. Raptor Forensics is a great utility to include in your kit and there are 239 reasons it's better than helix for this purpose.

Responder Pro - A review

Here's a short disclaimer before I get in to this.
*I'm not paid by nor affiliated with HBGary. This is an honest review of their product(s).*

A short while ago I received a demo copy of HBGary's Responder Pro product. A big thanks goes out to Rich and the HBGary team for letting me demo their tools. My demo period has now expired so I wanted to share my experience.

During my demo I used Responder Pro almost exclusively to analyze malware, and perform memory analysis. There's a bit of a learning curve with the product, mainly in getting used to the layout of the GUI which was at first a senseless morass of windows and tabs. After I adapted my thinking and used the tool a few times, the GUI made some sense.

Once I got acclimated to the GUI, memory analysis couldn't have been any easier. The GUI is pretty powerful and allows for a quick examination of the 'big win' components of memory - processes, modules, open files, open registry keys, network connections. Identifying process and DLL injection was in a word 'simple' once I figured out how the tool laid out the process and module information. Image(executable) extraction is simple - a right click does the trick.

A warning though. If you're using Antivirus products on the system you use this tool on, be prepared to redo your analysis or make exceptions for files and folders. More than once I was frustrated by having Symantec Endpoint Protection delete the extracted binary, leaving Responder in a state of confusion and inability to complete an analysis. I have many v.2 case files due to this.

The automated malware analysis of the memory dump was a huge timesaver. Based on a file called baserules.txt, a memory dump will be analyzed for processes and modules that are exhibiting potentially malicious behaviors. If you highlight a module, it will be selected for a deeper dive analysis. Did I mention it's a time saver? Analyzing module after module in a process can be tedious work. Having the information presented to you allows you to quickly weed out what looks normal from the abnormal.

My one nit about the automated analysis was the transition from 1.3 to 1.4. 1.4 had far too many rules commented out, and while this led to fewer false positives, it greatly contributed to more manual work because it missed a lot of things.

During my demo period HBGary updated Responder Pro from version 1.3 to version 1.4. The transition added interesting capabilities such as pulling out URL's from the memory dump as well as passwords. Harlan discussed this a bit while looking at one of my memory snapshot project images.

Memory analysis-wise Responder is right up there for commercial tools. I'd pretty much say it's the best around for the price point ($1000 for Field edition). It also integrates with Encase, which is nice for a lot of people.

And then there's the graphing for malware analysis. One of my colleagues summed it up accurately by calling it very 'seductive'. Now, graphing has been around a while for malware analysis. There's a difference though when it comes to using Responder. The difference is you don't have to screw around with the reindeer games that various packers use. When you're analyzing a memory dump of malware, you're seeing the unpacked malware and it makes for a very straightforward analysis. In more than one case I was able to do analysis in about an hour or so on something that would have otherwise taken a few hours. The ability to pull out a subroutine, and analyze it graphically and having the code available as well is a fantastic feature. Or, if you want to, you can begin by performing an analysis of a process, and looking at the strings. Then just pull the string you're interested in, in to the working canvas, and begin analysis on something that looks like it's of direct interest to you. That's what I was doing here. The bookmarking and layering made it almost photshop'esque. I only had to look at what was of interest and I could go back to it later. While analyzing virut.CF the bookmarking feature was very handy, especially when I discovered some Passthru driver configuration files intact while doing a graphical analysis. I won't get in to the differences between IDA pro and Responder Pro for analysis but I will say that I had a much faster time of doing analysis in Responder than in IDA, and I think the reason was due to using a memory dump rather than static binary analysis.

So that's enough talking about why I like the product. Case Study-wise I used Responder Pro to look at several poorly classified malware types during my demo. In the field I use Responder Pro to analyze several USB related malware variants that my other vendors called "downloader" or "trojan horse" or "SillyFDC". In a wave of compromises I didn't want any other tool for analysis. I reached for Responder Pro when I needed to do an analysis to determine scope and the REAL risk to data. I reached for Responder Pro when I needed to determine the capabilities of a few very nasty pieces of malware. Why? Because I needed accurate, actionable intel fast.

Just this evening I wanted to do an analysis of an InfoStealer variant I discovered in the wild. The tool I went for? Responder Pro. As I said though, my demo expired and I felt a bit lost. Gone was the quick analysis. Gone was the interface. I still have Volatility and Memoryze and they certainly have their strengths but I had gotten very used to using Responder. I still have the old tried and true tools around but it's a bit of a disappointment to go back to them.

The biggest issue I have is unfortunately not technical at all. It's price - which is currently the biggest concern for us. For $9000 I could license my entire team with IDA pro and train them all in Memoryze and Volatility.

Do I recommend the Responder family of products?

Absolutely. The products have a lot of strengths including time saving techniques and easy analysis and presentation of otherwise complex data sources. For many people in the industry Responder Field Edition is more than appropriate.

Responder Pro is an entirely different beast and to be frank I feel a little naked right now.

Flypaper

Years ago I played football and I can recall the day when my coach grabbed me before the game and gave me a pair of receiver gloves. He said "Here, now your hands are like flypaper." If you've never worn receiver gloves before I can tell you they have a sticky substance on the palms and fingers when the gloves are new. Not a ton, but enough to make them tacky...like flypaper.

While testing HBGary's Responder Pro product, Rich Cummings turned me on to a secondary product in their lineup. It's called flypaper. It's currently a free download and I've got to tell you it's been a great experience using it. The process is simple.

Load a virtual machine from a snapshot.
Run flypaper.
Execute the malware or binary of your choice.
Suspend the virtual machine.
Examine the .vmem file.
Unpause the virtual machine.
Stop flypaper.
Extract the flypaper log file - which happens to log changes to the system. (You could extract the file from the .vmdk if you were inclined of course.)


A quick look at how simple the flypaper interface is:


You're probably saying..uhh I do that anyways. Ahh but flypaper allows you to have great control over what can happen. For instance, you can block all network traffic to and from the virtual machine. You can also prevent processes from exiting. Why is this important? Well friends, have you ever tried to reverse engineer something that's packed with themida or armadillo? These are two of the most advanced packers out there and they are pretty useless when flypaper is involved. How about a multistage packed binary? When a program executes and loads in to memory, it's unpacked. Flypaper keeps it that way and allows you, the examiner an opportunity to look at a completely naked version of the malware. How's that for a time saver? How about that's flippin sweet? Is it 100% effective? No it's not, but it gives us a chance to examine malware without a lot of the pains involved with reverse engineering packed malware. And if you were to do the memory dumping with FastDump or FD pro, you could get a copy of the page file for complete analysis of memory. With Responder and Responder pro in the mix and the ability to analyze the pagefile and memory dump, HBgary is building an impressive suite.

Using RegRipper

I have been doing oodles of analysis lately (6+TB since December!) and have been making heavy, heavy use of registry analysis in each case. For this I've been using Regripper so I figured I would dedicate at least one post to it, and how I make use of it. I also happen to be a firm believer that someone can tell a person to use something 1000 times, but until they actually see it in use or can see the utility in using it, they are less likely to follow your recommendation. With that said, here's a few ways I use regripper.


1) Determine group membership.

Like no other tool I've used to date, the samparse module has saved me hours of analysis time in determining who belonged to what group and what privileges they had. Just this morning I saw some mailing list posts about determining why there was no user account listed for a particular account in the SAM on a windows XP box. The answer was rather simple - The account was a domain account.

Here's an abridged example of what I'm talking about:

User Information
------------------------------------------------
Username: Administrator [500]
Username: Guest [501]
Username: SUPPORT_388945a0 [1002]
Username: SUPPORT_3f151ab9 [1003]
Username: HelpAssistant [1004]
Username: ASPNET [1006]

Group membership information
------------------------------------------------
Group Name: Power Users [1]
Users: S-1-5-21-1461745249-492156796-3006755465-1119

Group Name: Administrators [3]
Users: S-1-5-21-296978250-731684933-3931576523-500

To explain, the top portion are the local user accounts. Under the Group membership section we can see the power users group with a SID/RID combination that doesn't fit with the system. How do I know this? This is easily determined by examination of the Administrators group section of the file. The Administrator account is a well known SID of S-1-5-N-500. As such, I now know the system SID and can say that the account in the power users group is NOT a local account. This can and *should* be correlated to the software hive analysis of the profilelist key and its values that details user account and the SID. When looking at the software hive, you can quickly determine the account name from the SID and the domain name in question.

2) Determine services installed.

Regripper has a great module to determine what services were on the system sorted by last write time. Comparing this to an exemplar list of windows services allows you to a) do data reduction and b) determine what services may have been installed or leveraged by an intruder.

3) Windows Firewall configuration.

I once had an incident where an external consultant claimed the firewall was not disabled by them(which is what caused the incident), however the firewall according to regripper was disabled, and other logs confirmed this with all roads pointing to the consultants.

4) Confirmation of devices in use on the system.

There's been a number of times when I could say to a customer that had been infected with removable media malware "You'll want to make sure you clean up these devices" or identify "rogue" devices that had been used on a system.

5) Determine network configuration.

In a world dominated by a lot of DHCP and variety of network usage, determining the last known IP address used by the system is invaluable, especially when you need to plug the IP address in to various network analysis utilities. I use this (and other markers) to make sure I've got the system I'm supposed to have.

6) Determine user activity.

Naturally there's a bunch of good things here to look at and every investigation includes a look here.

In short there's untold ways to use regripper for analysis. These are just a few small examples of how I've made use of the tool. I don't really know how many people are using it, but there sure are a bunch of people who aren't, and that's just a shame. It's a great tool that simplifies the process of registry analysis and simply stated it saves time. As we all know, time is money and saving both is important to everyone involved in investigations. Don't forget, as I showed in the video I posted some time ago, it can be run in concert with F-response to look at an otherwise "locked" registry hive on a remote system, while it's live.

There's much more I could say about using regripper but I imagine there will be plenty included in Windows Forensic Analysis second edition.

Redemption

Though I missed the true beta period I downloaded and installed the pre-release version of FTK 2.1 last night. FTK 2.0 left us all in a state of shock. Many questions and accusations flew around various industry forums and mailing lists. Prices went up, quality went down, and we were wanting what we paid for. A lot of faith was lost in Accessdata and their ability to provide a solid product moving forward.

Don't throw away your dongles quite yet. 2.1 is the product 2.0 was supposed to be.

Compared to 2.0, the installation of 2.1 was a breeze. The only missing link was that I needed to reboot to get KFF installed.

Some remarkable improvements I noticed are:
Speed - moving between tabs is as it should be. Processing is much much faster.

Resource usage - Obviously with a 64bit install FTK will use as many resources as can be thrown at it. I like this. I have a good machine, with plenty of resources and before I moved to 64bit, I always watched in horror as my resources just didn't get used.

Here's a shot of FTK just beginning to process an image:



Here it is 10 minutes in to processing:


Usability - Wow, when you click on a tab, you open that tab immediately, even while processing a case.



Does it still require a huge amount of resources? Why yes, yes it does. My test rig has the following specs:
8GB ECC 667 RAM
Dual Xeon 2.66GHz Quad Core processors
System drive is a raid-0 on two 146GB SAS drives
Database drive 3*500GB SATA raid-0

All in all I have to hand it to Accessdata. After all the tongue lashing they took when 2.0 was released, they listened to their customers, licked their wounds, and went back to the drawing board and worked to remedy the problems. I won't say just yet that all of the problems have been fixed. I just installed the product last night, and I'm still processing cases, but this is what I wanted to see - a solid product capable of living up to its marketing, and a product that gives me what I paid for.

Addendum: An 80GB disk took about 6 hours to process and index. I imagine if I had more disk available I could get it taken care of in under 4 hours. Compared to FTK 1.7 which took 20 hours to process an image, I'm happy, very happy with the performance. Currently, I'm processing two more images of 100GB and 150GB in the same case.

Drive Erazer

Historically I've always done disk wiping through DBAN. It's free, and easy to use. I have had a system capable of attaching plenty of drives and drive types for just this purpose.

Recently though, our tech shop purchased a bunch of Wiebetech Drive Erazers because the thought was it's easier and sometimes faster to just plug a drive in and flip a switch. Well, these devices fit that niche perfectly. They ended up tossing one at me and asked me to verify their functionality.

They ordered the "Pro" model which can do ATA-6 secure wiping as well as writing a simple zero pattern to the disk. So I first wanted to test the basic wiping functionality.

I hooked up a 13GB IDE drive and flipped the switch.

About 10 minutes and an 'xxd' check later and I had a disk full of zeroes that was verified. Not bad.

Next up an 80GB IDE drive. No problems here either. Approximately 40 minutes later I had a zeroed disk.

As I write this I'm about 50 minutes in to a 'secure wipe' of a 250GB SATA disk. This device also detects and removes HPA and DCO on the device, which I really like. I expect it to take a reasonable amount of time, around two hours or so. Weibetech states approximately 35MB/s wipe speed which is respectable for the pricetag and functionality. So far this little device is as good as advertised.

Procedurally I like devices like this, because a tech can easily attach a drive, flip the switch and go do something else while the device is working. As much as I like DBAN for my own use, I think these little drive erazers are very handy to have around, and they're extremely portable (fit in my palm) which only adds to the usability.

Some dislikes:
Counting blinks to determine error or time to completion. It's a little like morse code but for the price tag it's not a showstopper.

The jumper location in the device is all but unreachable unless you have fingers the size of paper clips. A precision set of needle nose pliers takes care of this though.

The IDE ribbon should be a little bit longer. At current length, you need to bend it too far to keep the hard drive flat.

Conclusion:
I like the drive erazer. For the $149 price tag on the Pro model I'd recommend it to people who don't want a computer dedicated to wiping disks, but a few more tests need to be completed before I "approve" it. I have a few small quibbles about design but none are major.

If you have thoughts about these devices or can recommend similar and similarly priced devices I'm all ears.


Addendum The 250GB disk finished wiping in one hour and twenty-two minutes.

Enterprise Forensics tools

After thinking about a few things over the past few days and digesting some comments and the presentations I saw down at techno security an idea popped in to my head regarding enterprise forensics tools. Currently there are two major players and one or two up and coming players in the field. I wanted to focus on the two major players, AccessData and Guidance. Please note that all of this is speculative and purely theoretical because I can't afford either of the two products to do any testing against.

This all began a few years ago when bad guys really started targeting applications, specifically those applications intended to protect end points on a network. Let me refer specifically to Veritas Backup Exec and Symantec Antivirus as references for this. To get even more specific I mean this one and this one. Having dealt with compromises related to successful exploitation of both products I thought to myself "what about other tools that I think will become as pervasive in the enterprise, what about enterprise forensics tools?"

Think about it a second..

They're agent based - If it's on the network and listening, it's attackable. They're services, which means they can potentially be killed or tampered with.

They require authentication - There's potential here to falsify or steal credentials.

They give full access to memory, and disk - There's potential here to bypass operating system protective mechanisms so attackers can gain access to sensitive data.

They communicate with a server - There's potential here to pivot an attack to get to the source, gaining access to other systems.

They communicate with the examiner machine - There's potential here to evade, confuse, corrupt, or otherwise negatively impact the examiner.

One communicates with an oracle database - where ALL case data is stored (AD) - potential here to destroy all investigations.


There's more potential spots to look but wow, those few open up wondrous places to begin exploring. Granted both vendors use encryption and AAA to supposedly protect access to the agents etc, but if someone can create it, someone will break it. If it's encrypted, an attack over the tunnel wouldn't be noticed by network forensics or network monitoring tools.

Eventually like I said I think these enterprise forensics tools will become as pervasive and mainstream as software like Antivirus, and will be as targeted by the bad guys as Antivirus has become. The question on the table is how secure are these products and their components?



Thoughts, comments and questions as well as any insights are definitely welcome on this one.

I'm excited

For the first time in quite a while I'm pretty excited. Just last week Matt Shannon released F-Response. F-response looks like it may shape up to be the best tool in my arsenal. Not because it makes analysis easier but because it facilitates analysis where it wasn't possible before and it does so in such a brilliant way that I'm just amazed. It also allows responders or examiners the opportunity to use the bulk of their toolkit safely and without the immense impact that many of our tools have on systems. When I've taught classes I specifically instruct people NOT to run AV, backups, and the other things that people like to execute to "investigate". This tool re-opens that door and can allow a first responder to actually respond to the incident, analyze with their typical toolset, and escalate when needed.

I'll be writing quite a bit about this tool and what can be done with it because I am just that excited about it.

FTK 2.0

Last week I re-licensed my copy of AccessData's FTK and I'll be installing FTK 2.0 when it's released. With the new product being tied in to Oracle 10G, one must wonder..will the forensic processing box now be vulnerable to both Oracle and FTK introduced vulnerabilities? I must assume that the answer is of course yes. What does that mean for investigations? Must we now prove that the processing machine hasn't been compromised at the database level as well as the OS? Is there a way to prove the database integrity within the product?

If the 10G implementation is a full installation, this also creates a lot of powerful capabilities for case comparisons. Can we do some fuzzy matching from case to case to see how similar they are in attack methodology, and post intrusion activity? This could be pretty exciting as far as case comparisons go. Could one begin to profile attacks and groups responsible in this manner? I guess we'll see.

It may be even easier to do data presentation with a database backend now as well.

Let's not forget the other cool capabilities in the more expensive versions of FTK..like distributed processing of cases.

application ballistics

Following on the tail of a few of my previous posts I wanted again to illustrate the reason for and benefits of having a tool mark library.

Take this photo in to consideration:



You can see clearly the shape of the object I took this blurry picture of. However, it's not necessarily recognizable unless you have experience with this type of object.

Given the picture you can make an assumption as to what the object is and what its purpose may be. You may even be able to provide a better description and explanation if you've dealt with it previously. You can then make an educated guess as to what it is. Can you identify anything other than a generic class that this object fits in to? If you had to conduct a comparison to this object in future cases, would this photo be of assistance? Probably not.

Let's clear it up a bit shall we?












Now we have some clarity. It's clearly a bullet of some type. Note the deformities, the rifling impressions, the slightly blunted tip, the other markings that coat the bullet. Note the shape of the bullet, the retention of its original shape, the lands and grooves, the twist, and even the corrosion. From looking at these class and individual characteristics we can ascertain a number of things. Imagine if we had the cartridge casing, a macroscope, or even the original weapon. We could determine a whole lot more if we had something to compare against, and our rate of accuracy and precision would increase dramatically.


This bullet followed a path during it's lifecycle - from original machining to being sold, to being loaded in to the stripper clip, in to the breech, down the barrel of a russian sks at a high rate of rotation downrange about 30 yards and through a few 2x4's to finally rest in the dirt behind them. It then made its way in to my backpack where it stayed for about 6 months.

Applications whether used for good or evil purposes follow a similar lifecycle. They are authored, purchased or downloaded, installed, used, then possibly they are uninstalled. If it's malware it follows a slightly different path but you get the idea. An application will have class and individual characteristics each of which will be caused by a number of factors and affect a system based on a number of factors as well.

*note to self*
The more I consider this the less I think it should focus on malware and focus more on applications in use. I think there would be a greater benefit if the focus was less on a specific type of software. Certainly malware has a place in the library however it shouldn't be that limited.


*EDIT* Anyone want to guess the bullet type?

A tool mark library - first cut

In giving this a little bit of thought, I am taking a first cut at what a tool mark library might look like. Not perfect by any means but it's a start perhaps.


Tool marks

Software name:
software version:
Author:
Downloaded from:
Intended use or purpose if stated by author:
Runs on operating system:
privileges required:
MD5/SHA1:

Characteristics:
Registry: Additions, modifications, removals, persistence
File System (files & folders): Additions, modifications, removals, accessed, persistence
Network connections: Additions, modifications, deleted
Services: Created, Deleted, Modified, persistence
Processes: Created, Killed
Users/Groups & Passwords: Created, Deleted, Modified
Logs: Entries created, deleted, modified

Other:
User configurable options and resulting behaviors
hash of each file created
binary packed/unpacked
PE header information of main executables
Restore point created


Thoughts?

yanking exe's from pcaps

Sometimes it seems that some pretty interesting tools just don't get the press they should.

Recently as in New Years Eve - I picked up a new binary in my honeynet. It came across as a themida packed binary that wouldn't run under vmware. After noticing the following snort alert:

[**] [1:2000419:7] BLEEDING-EDGE PE EXE or DLL Windows file download [**]
[Classification: Misc activity] [Priority: 3]
12/31-15:58:26.967376 70.22.81.49:2509 -> 10.23.62.175:445
TCP TTL:112 TOS:0x0 ID:60052 IpLen:20 DgmLen:1460 DF
***A**** Seq: 0xEF909157 Ack: 0x3FE9D46F Win: 0x41C5 TcpLen: 20

and not a whole lot else I decided to suspend the honeypot, copy the files over to my compromises directory, and hash them. I then took a good look at the network capture I picked up.

At this point since I could see who the attacker was I just plugged in the IP to a tcpflow command:

hogfly@oink:~/flows$ tcpflow -r 20071231.pcap host 70.22.81.49
tcpflow[20963]: truncated dump file; tried to read 1514 captured bytes, only got 392
hogfly@oink:~/flows$ ls
070.022.081.049.02368-10.23.062.175.00445
070.022.081.049.02509-10.23.062.175.00445
10.23.062.175.00445-070.022.081.049.02368
10.23.062.175.00445-070.022.081.049.02509
20071231.pcap

So in this case, which file should I care about? Well I know the file was transferred from the attacker to the victim, so I don't care about anything involving my honeypot as the source for this exercise. That leaves me with two possible files of interest:

070.022.081.049.02368-10.23.062.175.00445
070.022.081.049.02509-10.23.062.175.00445

Grand. Now..based on the snort alert I can narrow it down to just one flow of interest.

Taking a quick look to verify that the signature didn't just pick up 'MZ' in the content of the flow I find some interesting information rather quickly simply using trusty old strings and a hex editor (yes I have a full pcap and can just do some work with wireshark but it's always good to use alternatives).

hogfly@oink:~/flows$ strings -eb 070.022.081.049.02509-10.23.062.175.00445
XPOCUSTOMAdministratorEXPOCUSTOM
\\10.23.62.175\ADMIN$
\system32\smlogsvcc.exe

Hmmm...interesting. Looks like EXPOCUSTOM could be the netbios name of the attacking computer, and the user was Administrator. Could the binary transferred have been placed as \system32\smlogsvcc.exe ? Odds are yes.

strings -a gives us some other interesting output:
C:\Dokumente und Einstellungen\haase\Desktop\new server\running\rBot___Win32_Debug\rBot.pdb

Looks like someone with a name containing hasse had compiled a new version of rbot? It's certainly possible.


At this point I think it might be safe to say there's a strong possibility of having a good binary.

So how does one actually pull a binary from a stream like this?

I used pehunter from the honeytrap project at mwcollect.org. I didn't bother with the pehunter snort plugin for this exercise, I simply went after the pehuntd binary.

pehuntd is a standalone daemon and client application. The daemon listens on a local socket and the client simply throws data at the daemon.

after unpacking it I followed the instructions and compiled the binary as follows:
pehuntd: gcc -o pehuntd pehuntd.c pehuntd.h md5.c md5.h -Wall -Werror
pehuntc: gcc -o pehuntc pehuntc.c -Wall -Werror

Running the daemon is simple...

hogfly@oink:~/pehuntd-0.1$ pehuntd v0.1 (C) Tillmann Werner. Awaiting connections...


hogfly@oink:~/pehuntd-0.1$ ./pehuntc ../flows/070.022.081.049.02509-10.23.062.175.00445
Stream received, scanning 451657 bytes.
hogfly@oink:~/pehuntd-0.1$ PE file extracted: 449024 bytes dumped to /tmp/8740055003268cebd4e6c7310f07f761.

Cool, so now I have a binary that was extracted and it's in my /tmp directory. Oh..the file name is the md5sum of the binary.