Monday, November 5, 2012

PFIC 2012 Slides & Bsides DFW

Hello Reader,
                      With another presentation done here are my slides from PFIC, where I again presented on Anti Anti Forensics. This is a similar presentation to the one I did at Bsides DFW but  with more details on the actual structure of $logfile records and more information.

Slides can be found here: Slides

We are getting close to the official release of ANJP (Advanced NTFS Journal Parser) as we write up our official blog post to put up on the SANS blog. Until then, if you would like a copy of the version 1 free tool please email me dcowen@g-cpartners.com so I can get you going. Our goal is to get the community access to our research as quickly as possible!

I'm looking for conferences to spread the good word on journaled file system forensics for next year, so if you are looking for advanced content please let me know!

Tuesday, October 2, 2012

Updates and DFIR Conferences

Hello Readers,
                        I know I've been silent, our workload and conferences have kept me quite busy. Updates for you:

Book News
Computer Forensics, A beginners guide is out to copy edit or will be soon. Looking at an early Q1 2013 release to bookstores. I've been working on this book for way to long but having a child while writing a book will do that.

Hacking Exposed, Computer Forensics Third Edition we just signed the contract for this. Look for a new edition in 2014 with a lot of new content and new sections. We really want to keep this series not only relevant but expand its scope from the US legal system to the world.

Conference News
I spoke at Derbycon this past weekend, but not on forensics. I spoke on running a successful red team, which is both my professional past as well as part of the work I do at the National Collegiate Cyber Defense Competition. People seemed to enjoy the content and here are my slides!

My derbycon slides with notes!

I'll be speaking next at BsidesDFW on November 3, 2012 on Anti Anti forensics. I won't be staying very long after as I have to catch a plane to Utah but I do plan to go to the movie screening the night before so hopefully I'll see you there!

My last planned presentation of the year is at Paraben's Forensic Innovations Conference so if you're going I hope to see you there. I'll be doing my Anti-Anti Forensics talk again but this time be doing a live demonstration of the updated tool we've been showing in the blog here. which leads me to my next update

NTFS $Logfile Parser

After a good response from our beta testers we are feeling confident in elimination of bugs in what we are getting ready to release as version 1.0. In addition we got some great fixes after testing our parser on the NIST CFReDS project's deleted file recovery test images. If you are looking to validate a new tool or test a current one the NIST CFReDS images are great and well documented as a control.

We've decided to call the parser ANJP, Advanced NTFS Journal Parser, to have a clear and distinct acronym from anything else. We plan to expand our research into Ext3 and HFS+ after this and will have AEJP and AHJP parsers released at a later date to expand what we believe is a vital piece of information missing from your examinations. There is a lot of research around Ext3/HFS+ regarding recovering deleted files from the journal, but we can't find much focus on mapping out file creations, time stamps changing or files being renamed. All things possibly unique to the interest of the DFIR community. Our plan is to expand out our research so you can take advantage of all the data available to you.

So what will be in version 1.0?
  • Identification of deleted files with full metadata, in our testing on the NIST CFReDS images we recovered all deleted file records with full metadata.
  • Identification of files being created with full metadata
  • Identification of files being renamed with metadata before and after the rename.
  • Log2timeline output

But Dave, what about all the other cool things you've mentioned? 
There is much more we can determine from the NTFS $logfile, but we've realized that understanding it isn't as simple as just reading the csv it outputs. We don't want to release a tool that becomes a source for false positives and bad testimony so we are going to do follow the Viaforensics model (thanks for thinking this up guys!). We are going to be offering a one day training class that explains NTFS, the MFT and most importantly the $logfile. That class will explain how to parse the log, the event records, the redo/undo operation codes and how to stitch those together to find the information we provide in version 1.0.

Extending beyond that we will then explain how to take the Update Sequence Arrays, timestamp changes, file id/directory ids and tie them back into the MFT, recovering resident files, identifying the approximate number of external drives changes, determining how many systems an external drive was plugged into and be able to make good, reliable conclusions from them for use in your case work.  At the end of the class you'll get a copy of the super duper version 1.0 that gives you way more information that you will be qualified to draw opinions from. There won't be a dongle or a license or any other such thing. If you decide to give a copy to someone we just hope they don't testify to its results without taking our class.

In the future as we continue our research we may be able to reduce the possibility for error in the additional evidence sources and when we will / as we do we will update the publicly released tool to include those. Until then we think everyone is best served by this model that gets the most reliable evidence in everyone's hands ASAP and giving those who want to go deeper a chance to.

I hope to have version 1.0 released in the next week or two and I'll be posting it here when I do.

If you are running a conference and want us to do the ANJP training at your event let us know, we want to get as many people as possible using this as possible! When you see what all we can determine from the $logfile we think you'll agree.

What conferences do you get the most from?
I am planning my 2013 conference schedule and I've asked twitter and I want to ask you the reader, what conferences do you get the most from? I'm planning on CEIC, PFIC and possibly blackhat but  otherwise I want to hear your suggestions! Leave a comment and lets talk.

Sunday, August 12, 2012

Time to find a fancy hat, I'm speaking at Derbycon

Hello Reader,
                      I've been trying to find more conferences to speak at lately (If you are running a conference let me know) to let more people know about fun forensic artifacts. I've been selected to speak at Derbycon 2.0 but not for a forensic topic this time (though I did submit one). Instead the fine folks at Derbycon like my topic titled 'How to run a successful redteam'. If you've been following the blog you'd know that once a year I lead the national red team for the national collegiate cyber defense competition and have been doing so for 5 years now. We've learned alot on how to build and succeed as a competition red team and I thought it would be a good idea to share what we've learned.

So if you are going to at Derbycon and want to either:
 a) have a beer with me and talk forensics or
b) find out how to be a lethal red team full of 'i love it when a plan comes together' moments

Then I'll see you there! Let me know you read the blog if you don't mind it's always nice to know someone is one the other side of the screen.

Wednesday, August 8, 2012

Updates and status

Hello Reader!,
                       It's been awhile since we've talked. Things here at G-C have been pretty busy, the legal sector at least appears to be in a full recovery (knock on wood). While I haven't had time to write up a full blog post on some of the new things we've found over the summer, I did want to take the time to show you how our NTFS $logfile parser is coming. For those of you who attended my CEIC session on 'anti-anti forensics' or who downloaded the labs I posted afterwords you know that we had a rough parser and tests to recover the names of wiped files before.

I'm happy to say we've come a long way since then. The initial proof of concept parser was shown to validate the artifact and divide up the pieces into something we could then further understand. We now have a parser, that is still in development, that can go even further creating CSVs of human readable data extracted from those $logfile segments.

What does that mean? Well it means:
1. We can recover the names of deleted files and their metadata, even if its been purged out of the MFT. This includes the metadata associated with the file (directory, creation, modification and acess times).
2. We can recover the complete rename operation showing cleanly which file became which file. Including parsing out the directory, creation, modification and access times before and after the operation. This essentially will allow you to undo what a wiper has done (except for recover the contents of the file itself).
3. We can determine if files were written to other drives, and an approximation of how many. (This is not in the current version of the parsers and will require ist own blog post).
4. We can recover the original metadata of a file when it was created
5. We should be able to recover timestamps that have been altered

It's all written in perl (woo!) and we are going to release the source and documentation as soon as its ready (tm). In the mean time check out this awesome screenshot showing the parser recovering the metadata from 22 files that were wiped with eraser:




If you are need of this tool for a case immediately drop me a line and I'll see what we can do to help you out!

Friday, June 1, 2012

CEIC 2012 - Anti Anti Forensics Materials

Hello Possible CEIC Attendee,
   
           I always put my materials up after I give a presentiation. This time since I also made a couple labs to show how to perform this type of investigation into indentifying, detecting and recovering from anti forensic tools I am including those as well. There are 3 labs making up 10gbs of data compressed. The images are e01 and the cases are saved in Encase v7.04 since this was a guidance software conference. There is a lab manual for each lab as well in the root directory to walk you through what you are expected to find.

I'm putting this up on a dropbox account as they are the only file hosting service I could find without  max file size limit (that you couldn't pay to increase).

All three labs here:
https://dl.dropbox.com/s/no8w524ecshulz4/dcowen_ceic_labs.zip?dl=1

The ppt slides are here:
https://dl.dropbox.com/s/c0u980a53ipaq7h/CEIC-2012_Anti-Anti_Forensics.pptx?dl=1

As I've said in the prior post, I'm more of a talker than a powerpoint slide maker. So if you have questions based on the presentation/lab please leave them in the comments below and I'll do my best to answer them.

Also Lab 3 contains a preview of our $logfile research that we will hopefully be presenting at blackhat (please pick me blackhat review board).

If this type of lab download/review thing is popular with you readers I can put up more and we can do a forensic challenge style of blogging for a bit!

Sunday, May 27, 2012

New Project, Tool testing


One of the advantages of running a computer forensic company is that I get to buy lots of tools to use. When I was working for other companies I would have to wait for budget cycles and submit justification for tool purchases, but for the last 7 years I’ve been able to buy them as I needed them. In those 7 years we’ve accumulated a lot of tools that we use for different specializations and a body of knowledge related to them that I feel could be better utilized to share with all of you.



With that in mind I think it would be interesting to see how all these tools compare when working on the same forensic image. So with that in mind I’m going to start making some test images to see how data is interpreted from the same disk but in different image formats. I am going to start with the identification, not recovery, of deleted files and go from there.



My initial tool list to test includes:

Encase v. 7.04

FTK v. 4.01

Smart 3-26-12

X-ways forensics v. 16.5

SIFT v. 2.13



Any other tool you want us to test? Let me know in the comments below

I'll post my results as we finish a round of tests and as always a large case could easily distract me!

Wednesday, May 16, 2012

CEIC 2012 - Anti Anti Forensics

Hello possible CEIC attendee reader,
                                                            My class 'anti-anti forensics' will be tuesday at 2:00pm and is apperantly full from what I saw in the regestration page. For those of you who wanted to attend it but didn't get to sign up they normally allow people to queue up at the door to take vacant spots/empty space.

So why would you want to queue up? I'm happy you asked! In this class I plan to preview some research we've been doing on the NTFS $logfile. While I'm not ready to give a presentation dedicated to that, I've submitted to blackhat for that (please pick me blackhat reviewers), I will be showing what I consider to be amazing new tricks to defeat anti forensic tools using the NTFS $logfile.

As in prior presentations I will make my slides available on the blog afterwords for anyones review, but I don't feel that they really ever capture everything that I talk about. I'm much more of a talker than a slide writer so my slides typically just cover major topics and points rather than the details that I would hope you want to hear.

See you there!

Tuesday, May 8, 2012

New tools for shadow copes

Hello Readers,
                         I think a lot of us are still using the old tool Shadowcopy to explore shadowcopies from forensic images mounted. While we know how to mount volume shadow copies to mount points within our system, I personally always liked the interface shadowcopy provided me to jump between restore points and browser their contents. Since Shadowcopy hasn't been updated in over a year one I was happy to new someone else pick up the guantlet of a GUI based VSS explorer.

The entrant? Shadowkit which is currently available for free on the website www.shadowkit.com. I've tested the tool on my own systems it's quick and has some nice features that I've been wanting from Shadowexplorer such as:

1. File list exporting
2. Filtering shadow copies of your local system versus shadow copies from mounted images
3. drop downs for machine names as well as individual volumes backed up, preventing confusion with imported shadow copies
4. MAC and attributes displayed within the interface for each file
5. The ability to open files within the tool without having to export them, it places them in a temp directory for viewing
6. Extension filtering

In talking to the author he has more features planned with an eye towards the needs of the DFIR community so I'm expecting good things.

Monday, April 23, 2012

NCCDC 2012 Wrap up post

Hello Friends,
                        This post is here to give links to the two presentations I gave at NCCDC for those interested and contacts to red team members for those interested in known more about what happened to them.

Red Team Debrief PPT: https://skydrive.live.com/redir.aspx?cid=c252230f74663370&resid=C252230F74663370!848&parid=C252230F74663370!126&authkey=!AEdgB9WG-fF3pd0

Responding to the incident: https://skydrive.live.com/redir.aspx?cid=c252230f74663370&resid=C252230F74663370!849&parid=C252230F74663370!126&authkey=!ADnYRFJV9VCMK08

Red Teamers:
Mubix @mubix on twitter
Chris Nickers: @indi303 on twitter
Ryan Jones: @lizborden on twitter

i'll get more email addresses and twitter names and update this post as I hear back from them.

If you would like to watch the red team debrief, albeit with some bad audio, you can watch it here:
http://t.co/4umtDJnB

Monday, March 12, 2012

See you at CEIC

Hello Readers,
                        Looks like I'll be speaking at CEIC Tuesday afternoon 2:00pm on "Anti Anti Forensics". If you've enjoyed the blog/books/tweets I hope you'll come as we get into how I go about detecting and sometimes overcoming wiping/system cleaners in a hands on lab.

Tuesday, March 6, 2012

Making forensics faster

Hola Reader,
                     There are always bigger hard drives, at least for the near future, and more devices available to individuals every day. While the everyday work flow for an individual is drastically improved, hopefully, by obtaining this additional storage and processing power it only further compounds the amount of evidence a computer forensic examiner has to go through. It's not uncommon now for a single person to have over a terabyte of data between their laptop, desktop, mobile phone, tablet, hosted email, file sharing and backup services. The question then becomes how do we keep up with the larger volumes of data without allowing each individual to take a month to process.

There are several options out there, depending on your choice of tools (encase, SIFT, FTK, Prodiscover, SMART, etc...) to really speed up the processing of the evidence so you can get full text indexes built and artifacts parsed. In most cases the answer comes down to:


1. Faster CPUs to process the evidence
2. More RAM to process the evidence
3. Distributing the workload across multiple systems (if your software permits this)
4. Faster storage to hold the evidence

In my lab we've approached this from all of these points.

1. Faster CPUs to process the evidence
We have multi cored, multi processor CPUs on our systems. What we've found is that typically, unless we are password cracking, that the I/O from the disks can't keep up with resources available. Meaning our CPUs are never maxed out. So the CPUs are not the bottleneck for getting more speed.

2. More RAM to process the evidence
We have machines with up to 49GBs of ram, under large loads we sometimes see usage into the 30GBs but again because of I/O from the disks more than enough is available. So the RAM is not the bottleneck for getting more speed.

3. Distributing the workload across multiple systems (if your software permits this)
We've tried using FTK's feature that allows multiple systems to distribute processing across them. The problem comes in that the evidence is still being stored and accessed from system. Again the issue comes up the I/O from the disks can't keep up with amount of requests being made from the additional systems now requesting data to process over the network. So distributed processing alone did not speed up processing.

4. Faster storage to hold the evidence
Here we find the greatest benefit. Initially we bought large direct attached storage RAIDs to store and process our evidence. While these systems get us I/O speeds around 100-200MBs depending on the type of disks it still wasn't enough speed to max out the CPUs and RAM. So we started looking around at other options. When you start looking at larger/faster storage systems things can get very expensive, very quickly.

If we had a very large budget we could have gone for a RAMSAN, http://www.ramsan.com/, and gotten a couple terabytes of storage at 4GBs a second read and write speeds. That kind of I/O would clearly max out most systems attached to it and easily keep up with the demands of a distribute processing system.

Unfortunately we don't have that large of a budget for storage, especially not with the amount of data that we working with. A RAMSAN 810 according to this article, start at $45,000 as of 8/23/11. So we look at the midline prosumer range of solid state storage as they are faster than similar SAS 15k drives but priced around the same in the most cases for larger sizes. Most prosumer SSD disks can go up to 300-400MBs a seconds and are connected via SATA meaning you could easily turn them into a small RAID and load your images there. However again the cost of doing this can quickly scale up depending on the amount of storage you need to hold the evidence.

Instead we have been implementing is a middle of the road approach. Instead of loading the entire evidence set into faster storage we purchased a PCI-E based SSD card from amazon with read speeds of 1.5GBs and write speeds of 1.2GBs  it has a smaller amount of storage (we opted for 240gbs) but allows the most heavy part of the processing (dealing with all the data extracted from the forensic images) to be done on the fastest storage. To accomplish this in FTK we pointed the ADTemp directory to the PCI-E SSD card and our processing speeds improved dramatically. We were able to complete a full text index of a 149GB full forensic image in 1 hour. This test wasn't even optimal as the forensic image wasn't even copied onto faster RAID storage but instead was just attached via USB3.

We've since ordered PCI-E SSD cards for all of our evidence processing servers and will post most benchmarks as we move forward in our testing and processing. I would also like to expand our SSD storage to include the evidence storage media and database media but I'm doing this one step a time to find out what parts are getting me the largest increases in speed for the dollar.

Paul Henry (@phenrycissp on twitter) has already taken this a step further by putting all his pieces onto SSD SATA storage and integrating in the PCI-E SSD card for his temporary directory. His new issue is finding test images large enough to show meaningful results since its' processing so quickly So if you have a test image 100GBs or larger, please let him know!

Tuesday, February 28, 2012

The best feature you never knew existed

Bonjour Reader!,
I know I have large gaps in my blog posts, its not for a lack of ideas but it is for a lack of time. With the economic recovery in full swing in the legal world we are very busy.

However, I still need to finish my new book and start getting back to blogging more regularly so please feel free to harass me on twitter @hecfblog if I don't write a post once a week.

In this short post I am going to point out a feature in FTK that has existed since 3.3 atleast that I never knew existed. The feature is called 'export lnk contents' in ftk 3.3 and 'export LNK metdata' in ftk 4.0 and it may be the one feature that I wish existed in FTK for the last 8 years of using it. When I've mentioned what this feature is and what it does to fellow examiners each of them has said the same two things:

1. "Woh! This going to save me so much time!"
2. "Why didn't they tell everyone this was here?!"

So in relation to point number 2, let me do that for them.

HEY EVERYONE, FTK will now export out all of the metadata of a lnk file and the contents of the parsed lnks to a file (from atleast 3.2-4.0)!

It can do this with one, some or all LNK files just highlight them, right click a lnk and the context menu will show the option! Suddenly all the manual copy and pasting into a spreadsheet or running other tools (like tzworks lslnk) are no longer necessary. This is especially great when it comes to carved LNK files that may not actually be valid and break many third party tools when they try to parse them.

What all does it export you say?
Keep reading!

Surely there is no way they snuck in a feature everyone wanted and didn't tell anyone?
I sure didn't see it!

It must be missing something right?
Not that I can see! It exports out into a tab seperated file:
* Shortcut File - Name of the LNK file
* Local Path - The path to the file the LNK file is pointing to
* Volume Type - The type of volume (Fixed, Removable, CDROM) of the volume being accessed
* Volume Label - The volume label for the volume being accessed
* Volume Serial Number - The VSN of the volume being accessed
* Network Path - If this was done over the network, the full UNC path to the file
* Short Name - The 8.3 name of the file
* File Size - Size of the file in bytes
* Creation time (UTC) - When the file the LNK file is pointing to was created
* Last write time (UTC) - When the file the LNK file is pointing to was modified
* Last access time (UTC) - When the file the LNK file is pointing to was accessed
* Directory - If file the LNK file is ponting to is a directory
* Compressed - If file the LNK file is ponting to is compressed
* Encrypted - If file the LNK file is ponting to is encrypted
* Read-only - If file the LNK file is ponting to is marked read only
* Hidden - If file the LNK file is ponting to is marked hidden
* system - If file the LNK file is ponting to is marked as a system file
* Archive - If file the LNK file is ponting to is marked as to be archived
* Sparse - If file the LNK file is ponting to is 'sparse'
* Offline - If file the LNK file is ponting to is offline
* Temporary - If file the LNK file is ponting to is a ntfs temporary file
* Reparse point - If file the LNK file is ponting to is extended directory information
* Relative Path - The relative path to the LNK file
* Program arguments - Any arguements stored for the execution of the program
* Working directory - Where the executable will default for reads/writes without a path
* Icon - What icon is associated with the executable if any
* Comment - This is an outlook feature, not sure why its included
* NetBIOS name - The network names of the system the LNK file was accessing
* MAC address - The MAC of the system the LNK file was accessing

So the next time you are working a case in FTK and you want to know what was being accessed from external drives (and you are checking shell bags and other artifacts seperately of course) then make a filter for all file with the extension 'LNK' and right click on one and export all of them to TSV. Import that TSV into excel, sort by Local Path and your done! This may be one the biggest time savers I've found in FTK in years and I now use it on every case.

Have you found a feature you love that everyone seems to miss? Leave it in the comments below.

Saturday, December 3, 2011

Back to Basics, CD and DVD basic forensics

Well hello there reader,
At G-C (my company) we try to have an internal training topic for about 30 minutes to an hour every day (that I'm in the office). Often times we will go over case studies of recently solved cases but other times we get back to basics because you can't assume everyone knows everything you do. One class we recently did was on CD/DVD forensics and since it was received well I thought I should do a similar thing here on the blog. I admit I was watching the barefoot contessa's 'back to basics' show before i wrote this so the title is most likely influenced by delicious food.

I think a lot of people have forgotten about DVDs and CDs as important forensic evidence with the widespread use of cheap reusable USB storage (commercially introduced in December 2000 (Thanks wikipedia!)), but back when I got started (1999) it was very much 'a thing'. There are four important things we can determine forensically from a CD/DVD.

1. The volume name of the CD (always)
2. When it was burned (always)
3. What software made the CD (sometimes)
4. The previous burns (always)
and some easter eggs.

1. The volume name of the CD
All of the CDs I reviewed start with a ISO9660 session on the disk which began at an offset of 8000. You can see in the screenshot below that standard identifier has been set as 'CD001' which is the default for most burners when a ISO9660 session is selected. However what we care about is right after that the name of the CD is ' Oct 28 11 09:33'.




You may think, why do I care about this, this is the volume name that I can see in any tool? Well if you have a multi session disk the volume name will be set to the current session, this may be the only way you have to determine the labels of the prior sessions. We will talk more about sessions in 4.

2. When it was burned
Near the end of the ISO9660 session block are four time stamps, I've always seen them set to the same time. This is the time the CD/DVD was created.



Let's break the timestamp down to a more readable form:

2011102808333500è
2011102808333500è
2011102808333500è
2011102808333500è

As you can see each of them terminates with ascii character è which is hex E8. Breaking down an individual entry we can see that the time is:
2011 10 28 08 33 3500
So October 28, 2011 at 8:33:35am is when the CD was burned, notice this is one hour off of the CD label time. Note that this time is only as accurate as the system clock that burned the CD/DVD.

3. What burned it
Depending on what software burned the CD/DVD many of them will also place the name and version of the software in the reserved space of the ISO9660 session start. In our example we can see that the name of the software that burned it is 'PRASSI2.1.374'.





Doing some quick searches for 'Prassi cd burning software' reveals that this is Primo Prassi version 2.1.374 a now defunct company whose software was bundled with some CD/DVD burners.
Why do we care? If you are trying to prove that a CD/DVD was burned on a particular system matching the software name and version to what was installed on the system can be one indicator that you can use.

4. The previous burns
If you are inspecting a rewritable CD/DVD and it has had more than one write burned to it, then each of the writes are still available. There are multiple layers of burnable media within a rewritable disk and when inserted into a CD/DVD ROM your computer will only show the most recent session. When you image the CD/DVD using a tool like FTK Imager all the prior sessions will be viewable. This is why determining the name of the session may be important as we detailed in 1.

5. Easter Eggs
Sometimes you'll find something unexpected. The ISO9660 specification does not state what can't exist within the reserved space of the session start and systems don't parse for unused areas. For instance within MSDN DVDs you'll be Microsoft's name, address and phone number. What is contained within the session start beyond what we've described here will also depend on what the burning software programmer decided to place within it.

That's it, I hope this shined some light on a possibly forgotten set of facts. Let me know what you think, your comments help to motivate me to keep posting in between baby bottles.

Thursday, December 1, 2011

Oh look, I still have a blog!

Hello Readers!,
I know its been awhile but thanks for not sending any threats or rotten fruit. Things have been very busy around g-c with work flooding back in and the new book, which is very behind. This no reason not to try to keep up with all of you and our new research.

I'll follow up with a new blog post tomorrow, a simple short one about what many forgot about basic CD/DVD forensics. Until then, did you know I'm google+ and twitter?

http://twitter.com/#!/HECFBlog
https://plus.google.com/u/0/?tab=wX#104808728995007755708/posts

Feel free to add me/follow me/circle me while I attempt to get back into the swing of things, so many new things for us to talk about in this one way conversation.

Speaking of two way conversations, I've put into speak at CEIC again and I'm looking for other conferences. Let me know if yours is looking for one!

Wednesday, May 18, 2011

CEIC 2011

Hello Readers,
Thanks to everyone who came to my session at CEIC 2011, I hope you enjoyed it. Here are my slides: link that I used in my presentation. I'll have the code up soon for everyone to download. I'll be making one post per exchange version so I can explain the procedures.

Tuesday, February 22, 2011

NCCDC is coming - My favorite time of year

Once a year the fine folks at the National Collegiate Cyber Defense Competition invite a team of people to participate in their event as red or white team members. I'm happy to announce that I've been asked to return as captain of the red team this year again on April 8-10 in San Antonio, Texas. I got my start as a professional in network security and though I speak about computer forensics publicly we at G-C still do network security for select clients.

For those not familiar with CCDC it is a national competition that pits teams of college contestants who have to defend their network while continuing to deploy new business services against a team of people who are looking to ruin their day.While there is always a team who wins the national title I've always felt that it's the red team who always wins since we have the most fun.

Getting involved with CCDC is something I've always enjoyed doing and would recommend others do as well, if you are looking to volunteer as either a good guy or a bad guy you should go here http://www.nationalccdc.org/index.php?option=com_content&view=article&id=58&Itemid=70 to get involved at either the national or local levels.


If you are company looking to recruit the best talent emerging out of today's universities you could also benefit by sponsoring, as we have, the event and get access to these students before they can write their own ticket. To sponsor go here:  http://www.nationalccdc.org/index.php?option=com_content&view=article&id=59&Itemid=37

Friday, February 18, 2011

New year, New book!

Hello Readers,
                       I thought I'd take this weeks post to announce that I just signed the contract with McGraw Hill to write a new book. It will be called 'Computer Forensics, A Beginner's Guide'. It's meant for those of you already in the IT field who are looking for a jump start into your first computer forensics investigations. I'll post more details as I finish the manuscript but we are currently set to have in stores in early November.

Friday, February 11, 2011

Oh no, it's GroupWise!

Hi there Reader,

For many years when I talked to a client about their network environment, these would be my words 'Oh no, it's GroupWise!' but not anymore!

Read more »

Thursday, February 3, 2011

What are you missing? AIX

Happy February Readers,
I didn't want to miss last week's posting, but I also didn't have the time to make a quality post before leaving on a trip. So quality over quantity will hopefully gain favor with you. I'm taking a break in the What was wiped series to give myself some more time to gather what I need and instead I am continuing the What are you missing series in this post.
Doing forensics on specialized servers, which I will define as anything non wintel and whose file systems have no parsers supported in forensic tools, is an interesting challenge. You have to:
1. Research where the system log files exist
2. Determine what format the logs are in
3. Capture the metadata of the file system
4. Determine if the file system can be parsed by anything but the running OS
5. Determine if it's feasible to image the server via DD
6. Determine if here is any hardware specific evidence that exists
A good example of this would be an older AIX system as detailed below

Read more »