NCCDC is coming - My favorite time of year

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

Also Read: Oh no, it's GroupWise!

New year, New book! - Computer Forensics, A Beginner's Guide



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.


Oh no, it's GroupWise!

GroupWise server disasters - by David Cowen - Hacking Exposed Computer Forensics Blog


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!


It used to be that in order to get at the email data held within a GroupWise server (not the individual user archives) that you would have to setup a GroupWise server and then bring in the existing database as you would in a disaster recovery scenario.

You see GroupWise suffers from three principal items that made it hard to deal with:

1) Not as popular as other mail servers: this meant that fewer forensic tools were in a rush to support it.

2) Encrypted mail storage on the server by default:  which meant you couldn't just try to decode the binary structure.

3) Dispersed data structure: user settings are stored in one directory of databases, messages of less than 2k of size stored in another directory of databases and the messages and attachments over 2k in size are stored in yet a third directory in separate files.

All of these combined made it a real pain to deal with and a frequent way to make fellow examiners shudder when you brought it up.

That has changed since Paraben's Network Email Examiner (http://www.paraben.com/network-email-examiner.html) started supporting GroupWise. You can now take an offline GroupWise database and NEMX will open it up and be able to export out PSTs from it so the rest of your tools can deal with it.

So if you've never dealt with GroupWise before this is what you need to know:

1. Look for a directory that has the file NWGUARD.DB, this is the root of your GroupWise mail server. NWGUARD.DB, WPDOMAIN.DB and WPHOST.DB are your keys to the kingdom.  Using these files NEMX is able to access the encrypted messages and pointers across the three databases.

2. Make sure the following three directories exist underneath it:

                a) ofuser - this database stores user preferences, profiles and message headers.

                b) offiles - this directory stores the messages and/or attachments greater than 2k in size in separate files.

                c) ofmsg - this database keeps the message bodies for messages and/or attachments less than 2k in size.

3. Copy the parent directory you found NWGUARD.DB and three underlying directories out of the image and load it up in NEMX.

4. Export out the PSTs and smile knowing that life is much easier now.

One of the options to know/understand in NEMX is whether or not to populate a message the way Outlook expects it or to leave it as it was originally stored by GroupWise.

I'll explain, GroupWise stores either the sent date or received date of a message depending obviously if it was sent or received by the user. Outlook will populate the other field with the same date as the one populated.

So if you choose to produce it as it was originally stored some vendors and/or products will complain that there is null dates and some products will fill in a false date to normalize the data. It's important to be aware of this and ask those who will ultimately review and produce the data how they want to handle it.

I hope this makes your life a little easier, I know it's made mine much easier.

If you know of other offline GroupWise solutions please let me know!


What are you missing? AIX

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