Okay, let's get this blog back on track, shall we?
I recently had an opportunity to use the FSP in an engagement, and to be honest, it worked very well. I was pretty happy with how things worked, but I did find somethings that I want to improve upon.
In a general sense, here's how the engagement went...I plugged my laptop into the network and set up the FSP server component, listening on port 7070 (the default). After calling the MSSP SOC for the client to let them know that they'd see some traffic on this port and that we were responsible for it, I would walk to the server and put the FRU CD into the CD-ROM tray. I was working with a sysadmin, and he'd terminal into the server and launch the FRU command line...which I'd typed into a Notepad window, so that all he had to do was cut-n-paste it into the command prompt. Very quick, very smooth. Nothing was written to the hard drive, and things like the .NET framework weren't required to be on any of the systems.
So...I did mention some improvements. Well, it's been suggested (yes, Ovie, I did hear you) that I set up a site on SourceForge for the FSP and various other tools. So, I've set up an account and I'm waiting to hear back if they'll accept my submission for a site. Once I do get a site, I'll start posting the various tools I've put together. This includes the FSP, as well as the supporting tools, and others, like the Perl modules I've posted to CPAN.
I also need to start working on the analysis suite of tools, one of them being to correlate information collected by the FRU and sent to the FSP into a nice HTML format. That, and I need to put together a user guide. I keep thinking that the FSP has appeared on the CERT VTE and is included in Helix, but there's nothing in the way of a comprehensive user guide.
Oh, and one more thing...I've been working on a GUI for folks to use for launching dd.exe. A friend asked me to put this together, and I've just about got it done...I just have some minor adjustments to make, then I'll fully document the code and post it. The idea is to make it easy for folks who need to do so to dump the contents of physical memory by identifying various drives (fixed, removable, network, etc.) to write to, etc.
"Nothing was written to the hard drive, and things like the .NET framework weren't required to be on any of the systems."
ReplyDeleteHi Harlan,
Is this a reference to Mandiant's First Response?
The deployment model for this tool (the free version anyway) involves the responder bringing the agent software on a USB token or CD to the victim. Nothing needs to be installed on the victim, per se. Yes, .NET needs to be installed on the console where data is analyzed, but that is not the victim system.
Is that what you meant?
I need to try FSP, by the way. :)
Richard,
ReplyDeleteNo, no reference to Mandiant's tool. I have seen some tools lately the can retrieve information from systems, but require the .Net framework.
That, and I had one email with the question asking if .Net was required. I guess the reader wasn't familiar with Perl.
"I need to try FSP, by the way. :)"
Yeah, more folks do. ;-)
Hey Harlan, for GUI dd have you looked at Grab? You can find it on the Helix CD.
ReplyDeleteBrandon,
ReplyDeleteI am traveling right now and don't have my latest Helix CD with me. Does dd GUI for grab run in Windows?
Yes it does, it's under live acquisition. Basically you set your varialbes (through dropdown menu's and text boxes) and it copies the data to the clip board that you then paste to a cmd shell that autoruns. My only complaint with doing it through the GUI like this is you are writing data to memory (the clipboard).
ReplyDeleteInteresting...I'll have to give it a shot.
ReplyDeleteYeah, I don't think I like the idea of writing to the clipboard.
I posted the GUI code to http://sourceforge.net/projects/windowsir. It's in the upload queue, so it should appear soon.
There is a screenshot! ;-)