After the leak of Microsoft COFFEE into the 'wild' a tool emerges that will supposedly make life very difficult for a forensic investigator using COFFEE.

The tool is titled DECAF and is freely available, although not open source.

The tool does not to be installed, and when configured in 'LockDown Mode' offers a set of Counter-Forensics functions upon detecting a COFFEE process running on the computer. The following options Counter-Forensics functions are available:

• Contaminate MAC Addresses - Modify MAC addresses of network adapters to possibly throw investigators off course in the investigation
  
• Kill Processes - Eliminates
  
• Shutdown Computer - Self evident if possible evidence are in memory
  
• Disable network adapters - most forensic tools send their evidence onto a trusted network share - this will stop all external communication
  
• Disable USB ports - the basic blockade step to prevent COFFEE from working properly
  
• Disable Floppy drive - should you use floppy for evidence collection or COFFEE execution
  
• Disable CD-ROM - Same as USB and Floppy
  
• Disable Serial/Printer Ports - Got lost here, unless you have some specific tools or choose to print evidence this is not very useful
  
• Erase Data - Basic Windows delete of folders which you know may incriminate you. Won't do much good though since it can be
  
• Clear Event Viewer - Remove logs from the Event Log
• Remove Torrent Clients - nobody wants these found, especially on their company computer
  
• Clear Cache - Remove cookies, cache, and history from everywhere
  

Since most user's don't have COFFEE copies to test DECAF, it includes a simulator that triggers the reaction as if COFFEE process is active.

According to information from the site, future versions will have text message and email triggers so in case the computer needs to enter into lock down mode the user can do it remotely. Also there is a suggested possibility to run as a windows service.

But DECAF is far from being a magic bullet: In it's present form it has a lot of realistic issues that will prevent it from being successful. Here is my top list of issues

1. Related to one product and it's current mechanism of operation - DECAF is designed to react to COFFEE, and is built to react to the leaked version of the COFFEE code. In the long run, Microsoft can modify the way COFFEE processes operate which may render DECAF useless. DECAF needs to expand into an automated 'evidence eraser' independent of COFFEE.
   
2. Needs to be run under administrator context to be most efficient - You can't erase Event Log not change MAC address unless you are the local administrator. So usual corporate employees need to understand that their protection is limited to what their account is permitted to do.
   
3. It doesn't 'live' as a service - you need to run the process for it to be active. And any forensic investigator can see the tray icon and the process in task manager. While DECAF developers announce that it will run as service, as it is now it is as visible as a zit in the middle of a teenagers nose.
   
4. Fails on certain platforms - running it on Windows XP (virtual environment test) produced an error and failed the application. While this may not be the case with all WinXP, there is a probability that DECAF will fail on some computers.

Talkback and comments are most welcome

Related posts
New Helix3 Forensic CD - Welcome
Digital Forensics Framework - A Perspective Forensics Tool
Tutorial - Computer Forensics Process for Begginners
Tutorial - Computer Forensics Evidence Collection
Scalpel - File Carving from Partially Wiped Evidence Disk

Alternate Data Streams is a feature of the NTFS filesystem. In essence they were created to provide compatibility with HFS, or the old Macintosh Hierarchical File System. The way that the Macintosh's file system works is that they will use both data and resource forks to store their contents. The data fork is for the contents of the document while the resource fork is to identify file type and other pertinent details.



How do you create an ADS? Wonderfully easy: All you need to do is have the two files, and then send the file to be hidden to the ADS of the host file with a simple type command:

type file_to_be_hidden> host_file:name_of_file_to_be_hidden

The most frequent use of ADS for malicious purposes is to conceal the executable of a trojan/rootkit as an Alternate Data Stream (ADS) to a perfectly safe file. For instance, once an attacker penetrates a Windows system, he can easily hide the malicious payload for further access into an executable which is fairly frequently used - like Calculator.

Alternate Data Streams may also be interesting as a mechanism to hide and transport information out of an organization:
Once you include an ADS into a file, there is no visible change in filesize of the host file, only the modified date is changed. This makes it quite difficult to detect the Alternate Streamed file. Also, the ADS file does not change the MD5 hash of the original file, which may prevent systems which control file modification through hashing from detecting the hidden file. Here is an example:

C:\Users\user\Desktop>md5sum test.txt
d41d8cd98f00b204e9800998ecf8427e *test.txt

C:\Users\user\Desktop>type image.jpg>test.txt:image.jpg

C:\Users\user\Desktop>md5sum test.txt
d41d8cd98f00b204e9800998ecf8427e *test.txt

One would think that this method of information hiding is great to transfer any amount of information with an inconspicuous carrier file being sent over a network. But there is a catch: most data carriers will ignore the Alternate Data Stream, and here is the summary list:

• Zip, RAR or ARJ will simply compress the host file and disregard the ADS
  
• MIME and Base64 encoding (e-mail) will ignore the ADS entirely
• FAT32 (mostly used on USB flash drives) will loose the ADS since it's not supported.
• Steganography programs will read the bytes of the host file and stop at the EOF
• FTP and HTTP transfer ignores ADS entirely
• Recording the
  

But all is not lost. There are still ways to transfer data with ADS:

• Transferring the host file over SMB network to an NTFS target retains the ADS hidden file
  
• Copying the host file to an NTFS file system transfers the ADS hidden file

So the information theft scenario with ADS is mostly available to employees or trusted persons:

1. The malicious user will create a legal host file and ADS a file with information to be stolen.
   
2. He will convince the manager to take the legal file home to work on over the weekend.
   
3. Upon the manager's request, even if USB drives are restricted, IT will copy the file over SMB and onto the employee's USB - which is sparkling clean and conveniently formatted with NTFS.
   
4. All logs of the transfer will contain the transfer of the original approved file to the USB

What will you do in such a scenario? Talkback is most welcome!

Related posts
Be Aware of Security Risks of USB Flash Drives
5 biggest mistakes of information security

After Helix Forensic went commercial, the open source Computer Forensics is missing a tool that integrates required forensic techniques as well as Helix did.

The tool
A group which calls themselves ArxSys have developed a Python based Forensic Analysis Tool, which they call Digital Forensics Framework (DFF).



DFF can be installed on Linux and Windows, and is functional even under Windows 7. The general architecture of the tool is to create a central contained program in which different forensic functions can be added as building blocks to create a fully integrated forensic environment.
In comparison, most current open source tools are merely wrappers for a whole myriad of standalone tools.
While this architecture is a visionary one, it's strength is also it' weakness: all functions need to be written for this framework, which will slow down development of the DFF as a full solution. At it's current state of development, DFF can handle disk dumps in FAT, but not NTFS nor memory dumps.

Another very important drawback is that DFF has no functionality for Forensic Acquisition, so the forensic investigator still needs additional tools.

Conclusion
Digital Forensics Framework is still a very 'young' product. It is focusing only on forensic analysis, with no initiative on forensic acquisition and documentation. The strong sides of the product are the flexibility and ease with which new python scripts can be added.
At this moment, it's not the first choice for a Forensic Investigators tool-chest, but we will follow on the development of the product.

Talback and comments are most welcome

Related posts
Tutorial - Computer Forensics Process for Beginners
Tutorial - Computer Forensics Evidence Collection
Competition - Computer Forensic Investigation

On the previous article on proper information disposal, a visitor suggested that Darik's Boot and Nuke (DBAN) can be used for emergency evidence destruction. While it is quite correct, DBAN takes time to finish. So, what evidence can be recovered from a disk on which someone interrupted the DBAN process?

Example Scenario
We created a simulation of an interrupted information destruction. Here is the scenario:
An employee has been collecting illegal material on his corporate computer.

• The employee is accidentally notified that internal audit investigators will review his computer in several minutes
• The employee boots to a Darik's Boot and Nuke to destroy the disk contents
• The investigators intercepts and disconnect the power to the computer before DBAN finishes

Analysis
Since DBAN will overwrite information, it can be assumed that the File Allocation Tables are destroyed, as well as some of the data.

1. The investigator creates a DD image of the disk drive, as presented in the Tutorial - Computer Forensics Evidence Collection
2. The DD image is loaded into the Helix investigator computer
3. All strings are extracted from the image using the 'strings' command - this activity creates a huge file that needs to be analyzed manually
4. All possible files are extracted using the 'scalpel' file carving tool - this is an automated tool which can search for a lot of known file types and tries to extract them by matching the beginning and end of the file
5. The carved files and strings are analyzed one by one. Most of the carved files are useless, since there is fragmentation on every drive so part of the files are lost, or the carving tool cannot match the other parts of the file.

Conclusions

• While evidence recovery from a partially wiped drive is possible, it is both difficult and time consuming to achieve. At any rate, no investigator can guarantee successful results.
• Also, it must be noted that after the first pass of the DBAN write, a very large percentage of information is already destroyed, so one has to be very lucky to walk in on the person while he/she is wiping the hard drive and interrupt the process on time.

Talkback and comments are most welcome

Related posts
New Helix3 Forensic CD - Welcome
Competition - Computer Forensic Investigation
Tutorial - Computer Forensics Evidence Collection
Tutorial - Computer Forensics Process for Beginners

E-fense has published a new version of their acclaimed Helix Forensic Live CD. It is now in version 2.0.

UPDATE: Helix3 is no longer a free product. e-Fense decided to make it a commercial product

Just as the old version, the new one contains two major components

• A LiveCD (Based on Ubuntu) - A full blown forensic toolkit with a nice all-encompassing set of tools.
• Windows set of tools - which allow the user to use a subset of forensic tools within a running windows system (most often during first response).
  

The Windows toolkit is maintaining the same interface as before, but the windows based application set is coherent, there are no missing applications. The previous version had a number of links in the windows toolkit that weren't working, which could cause a lot of grief at the wrong time.

Just a reminder of the Windows Helix Menu


The Linux LiveCD interface has seen a major overhaul. It is now based on Gnome, and the overall interface is much better organized.

The following screenshot depicts the new Helix boot menu


Unfortunately, probably in search of a better overall performance, it is departing the Forensic track and moving much more into mainstream - The toolkit is missing a lot of nice new Forensic tools that could have been installed and utilized. Hopefully, they'll be included in the next version.
There is one new major feature that was missing from the previous version - the LiveCD can now be installed on a hard drive - effectively creating a full blown Forensic investigation computer without the need to lug around a bootable CD.

The installer suffers from several bugs, so make sure you partition the target hard drive manually - the automatic option doesn't work

The following Screenshot depicts the installed version of Helix


The new version of Helix is much easier to use and overall a much more completed product.

UPDATE: Helix3 is no longer a free product. e-Fene decided to make it a commercial product


Talkback and comments are most welcome

Related Posts
Tutorial - Computer Forensics Process for Begginners
Tutorial - Computer Forensics Evidence Collection

Analyzing an incident when the manufacturer claims that it's an operator error and the operator claims that it is an application error is one of the most daunting tasks of a security officer.
And this is a type of incident that the security officer will be called upon to investigate simply because the management needs an independent observer and has doubts both in the operator as well as the manufacturer. Here is what to do when thrown into the fire

Prerequisites

1. Do not let the manufacturer's expert be the one that leads the investigation. If he insists to be involved, make it clear that this is your investigation and that he has to ask permission for and explain any action he wants done on the database and application during the investigation.
2. Know a bit of SQL or bring someone that you trust that knows SQL.
   

Tools of the trade

• Toad for Oracle and Query Analyzer
• MS SQL Server Management Studio for SQL Server
• Event viewer for Windows and
• Syslog and text log files for Unix/Linux
• Notepad, hi-res camera or screenshots for everything.
  

Incident Investigation Process

1. Gather as much information as possible - even gossip!
• Talk to the witnesses of the incident.
• Establish who else worked with the application during the incident discovery
• Document the events that lead to the discovery of the problem and their timeline
• Document any data involved in the process - account numbers, exact names, values, currencies - anything that can be found in the database. Do this for both the clean and and corrupt data
• Gather screenshots of the application of the events that lead to the discovery of the problem
2. Establish a time interval of the incident
• Choose a database backup closest to the time the incident has been identified and Request that a database restore be done and the users to verify that the restored database is in good condition.
• If the database is 'good' then the incident occurred between that backup and now.
• If the database is 'bad' repeat with an earlier backup
• Repeat until you find the closest 'good' and 'bad' backups - the incident has occurred sometime in that interval
3. If possible, try to reproduce the conditions of the incident
• Starting from the known 'good' state - a non-corrupt database ask the users to repeat their activities
• Observe/Film the user while performing the activities in the application
• Run a profiler/logger type of tool while the users are working to capture all backend activities on the database
• Follow through until the application is closed and all sessions are torn down - there can be a closing script that is a problem
4. Identify key data repositories
• Consult the documentation and captured queries if available to identify the tables that the corrupt data is kept in.
• If there is no usable source, use trial and error: The tables are usually named in a logical manner related to their purpose - so match them to the statement of events to find which tables are relevant.
• In order to confirm that the right tables are identified, find at least some of the documented data involved in the incident in these tables. Don't be disappointed if you miss at first - they MUST be somewhere!
5. Look through the audit and/or the logs of the database to identify which updates or changes were made in the database.
• This is a very problematic step - some applications and databases will not have any audit, or a small amount of audit.
• But almost all applications have a form of application trail - a table or set of tables that logs the action to be or was done, mostly because a lot of application actions are dependent on each other so they need to create a unique identifier (key) in one table to be referenced further.
6. Match the described timeline with the database logged actions as closely as possible.
• Consult the witnesses of the incident during this process - tell them that you notice certain type of event at certain time - this reminder triggers memory - they'll remember more detailed actions of their work!Add log details and timestamps at each step of the timeline
7. Discuss Observable Trail With Manufacturer and Users
• If you find a proof of a bug or human error you're in luck. Write a report and recommend corrective and preventive measures.
• Most likely, you'll find a gap in the events right where the incident occurred (interval of minutes) but the trail of events will indicate what was the next step: whether the program malfunctioned or the user made a flagrant error. Then you need to confront the manufacturer and users with the problem. Ask for a recreation of the actions with both parties present and with full logging. The log will give the actual event.
  

NOTE: Non reproducible errors are possible - If the error cannot be reproduced, then that is a report also. But then you need to increase the logging level to maximal possible level until the problem resurfaces.

Related Posts
Tutorial - Mail Header Analysis for Spoof Protection
Tutorial - Computer Forensics Process for Beginners
Tutorial - Computer Forensics Evidence Collection
The SLA Lesson: software bug blues

Talkback and comments are most welcome

The Computer Forensic Investigation Competition is closed, and here are the results

What was there to be found:

• Tshark sniffer - part of the wireshark suite in /moodle/enrol/paypal/db
• NetCat tool for backdoor creation - renamed as MyTool.exe - in /moodle/auth/ldap
• An MP3 of Sergio Mendes & Brasil 66 - Mas Que Nada renamed as html document - in /moodle/auth/imap
• A TrueCrypt rescue disk ISO renamed as MyDoc.doc in /moodle/lib/geoip/Documents/
• OSSTMM Penetration Testing Methodology with penetration details in deleted file osstmm.en.2.1.pdf in /moodle/enrol

Finding the above was suffucient to win the competition. Alternatively, instead of OSSTMM you could find the below two items

• A decoy metasploit developers guide pdf in /moodle/lib/geoip/Documents - actually, that document has nothing to do with direct hacking unless you discover the
• metasploit framework remnants of a deleted metasploit framework in /moodle/lib/geoip/Documents
  

Who did the investigation (in chronological order of reporting the findings - earliest first)

• Lawrence Woodman - Found 4 incriminating pieces of evidence. Missed the real penetration tutorial and focused on the dummy - Metasploit.
• Tareq Saade - Found 4 incriminating pieces of evidence. Missed the real penetration tutorial and focused on the dummy - Metasploit.
• Bobby Bradshaw - Found 3 incriminating pieces of evidence. Missed both and the dummy penetration testing documents (Metasploit and OSSTMM) and missed the Truecrypt Recovery CD Iso
• Daniele Murrau - Found all incriminating evidence. The utilized toolset is Autopsy as part of Helix distribution
• Lesky D.S. Anatias - Found all incriminating evidence. The utilized tollset is PyFlag and Sleuthkit
  

Other Participants - did not qualify for final review because they did not send details of methodology nor findings (no particular order)

• Phil (no last name) - reported finding 2 pieces of evidence, but did not send methodology used nor details of findings
• snizzsnuzzlr (obvious nickname) - reported finding 5 pieces of evidence, but did not send methodology used nor details of findings
• Fender Bender (obvious nickname) - reported finding 3 pieces of evidence, but did not send methodology used nor details of findings
• Sniffer (obvious nickname) - reported finding 2 pieces of evidence, but did not send methodology used nor details of findings

And the winner is - Daniele Murrau

Here are his conclusions and methodology as a downloadable PDF

We are also naming two honorary mentions

• For speed - Lawrence Woodman, who produced a nearly full analysis in a tremenduosly short time, but most probably missed the OSSTMM and the metasploit remnants because he was in a hurry
• For thoroughness - Lesky D.S. Anatias, who discovered ALL evidence, including the metasploit remnants

Related posts
Competition - Computer Forensic Investigation
Tutorial - Computer Forensics Evidence Collection
Tutorial - Computer Forensics Process for Beginners

Talckback and comments are most welcome

Shortinfosec is hosting a computer forensics competition.
In the competition, you will have to analyze a submitted disk image for incriminating evidence, as per the scenario below

Scenario
The investigators suspect that the employee was doing the following illegal activities:

• Sniffing IP traffic on the network
  
• Creating back doors to his PC
  
• Stole and copied a CD-ROM with confidential content
  
• Downloaded copyrighted music
  
• Used a specific penetration tutorial document to perform most of his actions

The investigators found his PC turned off. They performed a DD copy of the surviving partition and sent it to you for investigation.

Competition materials
Download the evidence image here (compressed as hdb1-img.rar)

• hdb1-img.rar (rar compressed disk image containing hdb1-img.dd)
  
• Verification sum of hdb1-img.dd:
• SHA1SUM 60642d113d40cb583df0b0654cbc83ffca63f886

Rules of the competition

1. Each competitor should submit his summary report (indicating only the number of discovered evidence) as a comment to this post to establish time of solution.
   
2. Each competitor should submit a detailed description of the utilized process of to discover the evidence in an email sent to shortinfosec _ at _ gmail dot com.
   
3. All solutions must be submitted before midnight (CET) 20th of August 2008.
4. The ultimate goal is to find one incriminating evidence for each suspicion.
5. It is fully acceptable to submit a result with less evidence found, if you feel that there is no other evidence to be found or you cannot discover it.
   
6. The incriminating evidence may be disguised (renamed, compressed).
7. Each competitor can withdraw and resubmit a better evidence before the submission deadline
8. You can use any type of investigative tools that you need, as long as you maintain the integrity of all evidence (proven by a SHA1 or MD5 hash). The utilised tools must be documented in the detailed submission.

Reward

• Unfortunately, there are no financial rewards to this competition.
  
• The first competitor to discover all evidence or the competitor who discovered the most evidence before the deadline will be the winner. His result will be presented as an analyzed solution on Shortinfosec.
  
• Also, if the winner owns a blog or a site it will receive a separate detailed review on Shortinfosec.
  
• All other submitted results, regardless of discovered evidence will be published in the results as honorable mentions, with links to their respective blogs/sites
  

We hope to have a good and fruitful competition

Related posts
Tutorial - Computer Forensics Evidence Collection
Tutorial - Computer Forensics Process for Beginners

Talckback and comments are for the competition

In the age where a huge percentage of all attacks are done through e-mail, very few of us know how to analyze where this e-mail was sent from. This analysis must go beyond the sender e-mail displayed in your e-mail client (which are easily spoofed). Here is a simple tutorial on analyzing Internet headers.

I. Where to find the e-mail headers?
A very frequent question. Let's review the common e-mail reading interfaces and where you can see the e-mail headers in them:

• MS Outlook (all versions) - Point to a suspect email in your inbox and right-click. On the context menu, select Options. A new window will appear. In that window, the e-mail headers are displayed at the bottom, in the box titled Internet headers.
• Outlook express (all versions) - Point to a suspect email in your inbox and right-click. On the context menu, select Properties. A new window will appear. In that window, click on the details tab. The e-mail headers are displayed in the box titled Internet headers for this message.
• Gmail - When you open an e-mail message, at the top there is a link titled "Show original". Click on it and a new browser window will appear, with the e-mail header at the top.
• Yahoo Mail - When you open an e-mail message, at the bottom there is a link titled "Full Headers". Click on it and the windows will re-render showing a very nice presentation of the e-mail header at the top.

II. How does e-mail headers work?

First, lets review how the SMTP (Simple Mail Transfer Protocol) works to transfer your e-mails. Let's assume that you are sending an e-mail message for mailto:webmaster@shortinfosec.net.

• When you click send, your local mail server will receive the e-mail message for further delivery.
• The mail server will then break the recipient address into user (webmaster) and domain (shortinfosec.net)
• The mail server needs to know which mail server knows how to deliver an e-mail to webmaster@shortinfosec.net . For this, it will query the DNS server asking for a Mail eXchanger (MX) record for the domain shortinfosec.net.
• The MX record is actually a DNS name of another mail server which is registered as authoritative for a specific domain - i.e. knows what to do with e-mails for that domain
• The mail server contacts the MX server the shortinfosec.net domain and delivers the e-mail message. Then the MX server will follow internal rules on how to deliver the message to webmaster@shortinfosec.net
• There are specific mail servers on the Internet called relay servers, which don't actually hold real mailboxes. They are usually hosted by ISP's and provide availability to receive e-mails for many domains, which are then internally delivered to the real mail servers residing on slow links or hidden behind corporate firewalls.
• An e-mail message may traverse multiple hops on the Internet before being delivered to the recipient.
  
• Each mail server that processes an e-mail message during it's transit will add a line to the e-mail header of the e-mail message. A legitimate mail server will NEVER rewrite or alter an e-mail header. This was originally designed for troubleshooting, but is very useful in spotting scams and fake e-mails

III. How to I analyze the e-mail headers?

Let's review a real life example: The following e-mail headers are from an e-mail that supposedly arrived from Chase Bank, and is a clear example of phishing attack (click for larger image)

NOTE: The real recipient, domain and it's servers are anonymized .

ANALYSIS:

• The message claims that it was sent from smrfs@chaseonline.chase.com. This information can be very easily forged, so NEVER trust that information.
• The useful information is in the "Received:" lines. Each of these lines represents a hop between two mail servers on the path from the sender to the recipient. These can also be forged, but there is a catch: A malicious mail server can forge the current headers, and at the end will have to send the mail to legitimate mail servers. The legitimate mail servers WILL RECORD the IP address of the sending e-mail server, and this information will ALWAYS BE TRUE.
• So, the malicious sender has no control over the Received lines of the header.
• The "Received:" lines are stacked on top of each other, so the first hop will be the lowest, and the last hop will be the first in the header. Therefore, to properly follow the path, read the lines bottom up.
• So, reading our e-mail header, this e-mail was sent from an ADSL IP address registered to an ISP in Warszawa - Poland, and then had 2 more hops in the protection systems of the delivery ISP. Visually, this was the path of the mail:

IMPORTANT - You can easily check the registered owner of any address using SamSpade.org

• Suddenly, it's obvious that this message has a slim to none chance of being sent by Chase Bank. There is absolutely no reason for them to send it via an ADSL address in Poland when they have huge corporate servers
• There are two more elements that can be useful for analysis, although they can be forged:
• X-USER_IP - the apparent IP address of the sending client computer
• User-Agent- the apparent mail client program used to send the e-mail
• In our example, the X-USER_IP points to 12.177.160.117 - an AT&T WorldNet Services address, and the User-Agent claims to be Tumbleweed Mail Gate server - both of which are highly suspicious, so we discard them
  

Conclusions

When in doubt about the authenticity of an e-mail message DON'T follow instructions within it and DON'T click on the attachments inside it. Instead:

1. Open the e-mail headers and read where it came from. Usually, it's very easy to identify a fake message just from the path it took on the internet.
2. If you can't identify the problem, just extract the headers and send them to your IT and Security Officer for analysis.

Related posts

Tutorial - Measures for minimizing Spear Phishing Attacks

Example - SMTP message spoofing

Talkback and comments are most welcome

Following up on the Tutorial - Computer Forensics Process for Beginners , here is a step-by-step tutorial on how to process a suspect computer to obtain dumps of RAM memory and Disk Drive using Helix Forensic CD.

Our suspect computer is a Windows XP Virtual Machine.

Our Example Forensic Toolkit

• Helix forensic CD - your basic tool for the investigation
• Evidence USB - 16 GB Capacity - for removing smaller evidence files from the evidence computer
• Analysis computer - a windows laptop, VDK driver, for the analysis computer (if using windows) - this driver will enable you to mount a DD image created during the evidence collection
• Sophos Antivirus and A-Squared Free Antispyware detector software for the analysis computer

I. Running state evidence collection

1. Insert the Helix CD in the suspects computer CD/DVD drive. The Helix has an autorun so should start immediately, but be careful. If you are logged on as anything other then an administrator, you won't be able to make a dump of the full physical memory. So close the autorun, and choose the Run as option to start the Helix software, and provide the Administrator credentials.


2. WARNING - DO NOT log off the session in order to log on as an Administrator! Ending a session will inevitably change and contaminate the content of RAM, since a lot of processes are closed upon logoff.




3. When Helix starts, there will be a warning screen stating that Helix won't be able to protect the suspect OS environment from changing, since it's running within the suspect OS environment. But, since there is no other way to take a snapshot of the ram memory, just choose accept.




4. You will see the startup screen of the Helix tool. The first icon is just a preview of system info, so it's not too useful. Go ahead to the second option – acquisition. It will prompt you for the source. Choose physical memory, and direct the output to the evidence USB drive.
5. Acquisition will prompt you for the source to be dumped – choose Physical Memory
   It will ask for second confirmation and will start the dump




6. After Memory Dump is finished, choose incident response (3rd icon on the Left menu) and click on the small arrow to go to the second screen (shown below). Run WinAudit



7. Click on the only link and let it perform inventory of the system. Save the result as a PDF on your evidence USB

After Winaudit finishes, close it, and close the Helix mainwindow. It will ask whether you like to record all activities in a PDF file. Confirm that you wish to and save the PDF on your evidence USB.
The above process will create an MD5 hash of the memory dump on the evidence USB. Open this file and take note of the MD5 hash.

II. Disk drive evidence collection

1. Turn off the computer ungracefully, pull the plug - this will prevent any possible shutdown scripts from running and possibly erasing data on the computer.
   
2. Boot it up again, and from the BIOS select to boot from CD-ROM. In a real corporate investigation, you may need assistance of IT to provide passwords, since most corporate PC's are set-up with BIOS password and disabled from booting from CD to prevent possible information theft.


3. Boot the Helix Linux OS


4. When booted, select Adepto from the Forensics Menu




5. Similarly to the memory dump above, select the drive you wish to make a dump of, and select your evidence USB as destination. For hash, you can choose severa. The example is with SHA1. After the dump is finished, choose the last tab (report) and choose to save the dump report as PDF to the evidence USB.


6. Copy all files to your analysis computer, and verify the hashes of the memory and disk dumps again using md5sum and sha1sum, whichever you used initially.



7. Using VDK, mount a copy of the disk image for investigation. The mount command is: vdk open path_to_dump_file\dump_filename.dd /L:free_drive_letter

HERE You can download and review the forensic log documents created in this tutorial (5.19 MB ZIP file)

Helix_Evidence_Collection_Sample_Logs.zip
Verification sums:

• SHA1SUM c7d189a78a715fd96127677d39d5ace1d5854ea5
• MD5SUM 9b61fad0cf4418175cb7e387c6962c49

This concludes the easy part of computer forensics - evidence collection. Shortinfosec will follow-up with exercises of the analysis part.

Related posts

Tutorial - Computer Forensics Process for Beginners

Talkback and comments are most welcome

Computer forensics is currently a very popular term, and a lot of conferences are organized and books written on the subject. This, together with the popularity of the CSI series, brings an aura of certain very special, even magical steps that forensics teams use. In reality, the computer forensics job is a standard process, and every one of us does parts of the process when we debug our computers. So, here is a simple tutorial on what is involved in computer forensics:

Computer forensics process


Below is a diagram of the forensics process. It is a generic process, but applies in computer forensics.

In order to properly apply the forensic process to computers, let's expand the generic diagram into the following:

As you can see, in computer forensics, a lot of evidence can be collected while the computer is running. That is a one-shot chance, and you'll never have it again when you turn off the computer.

Your Forensic Toolkit

Every trade needs it's tools. For the beginner investigator, here is my recommended toolkit:

1. Helix forensic CD - your basic tool for the investigation
2. Digital camera - capturing physical state of the suspect computer
3. Evidence USB - 4 GB Capacity - for removing smaller evidence files from the evidence computer
4. Evidence USB hard drive (500 GB will be enough for most purposes) - for making an evidence copy of the disk drive
5. Analysis computer - probably a laptop, but sparkling clean - no viruses, Trojans, cookies or similar wildlife on it, since they can corrupt the evidence. Even if the evidence isn't corrupted, it may be considered as contaminated and become inadmissible in a formal case.
6. VDK driver, for the analysis computer (if using windows) - this driver will enable you to mount a DD image created during the evidence collection
7. Antivirus/Antispyware/Rootkit detector software for the analysis computer

Steps of the forensic process process
1. Evidence collection

1.1. While the suspect computer is running

• Make an image of the RAM Memory, and store it on the evidence hard drive/USB. Make MD5/SHA1 hash of the image and save it and write it down in a notebook.
• Make an inventory of all processes, network connections, installed software, hardware, everything you can about the computer. Save this in a file on the evidence hard drive/USB. Make MD5/SHA1 hash of the file and save it and write it down in a notebook

1.2. When the suspect computer is off

• Make an image of the hard disk drive and store it on the evidence hard drive/USB. Make MD5/SHA1 hash of the image and save it and write it down in a notebook
• Photograph the suspect computer from all sides. Save the pictures on on the evidence hard drive/USB. Make MD5/SHA1 hashes of the photographs and save them and write them down in a notebook.
• If any immediate physical tampering is apparent, photograph it specifically, and possibly expand the investigation with a forensic expert who will look for evidence regarding the tampering method (fingerprints, tool markings)
• Open the computer and photograph the interior under good lighting. Save the pictures on on the evidence hard drive/USB. Make MD5/SHA1 hashes of the photographs and save them and write them down in a notebook.

2. Evidence analysis

• Load copies of the evidence images into your analysis computer. Confirm that the copies have the same MD5/SHA1 hashes as the original noted ones.
• Search the raw images of the ram memory and the disk drive for strings, and save them for future reference

All following steps need to be used in the context of the investigation, so there is no specific exact step to use

• Review the strings dump for specific keywords
• If there are specific keywords related to your investigation ('payroll', 'salary', 'password', someones user name or e-mail address), search for those strings in the raw images. Save the results for future reference.
• Mount the disk drive image as a read-only drive. Scan the drive for viruses, rootkits and spyware. Save the results as screenshot or log file
• Analyze the event log of the suspect computer for any anomalies. Log anomalies with times of occurrence
• Analyze the running processes log of the suspect computer for any suspicious processes. If found, refer back to the memory dump to investigate the process (memory content, using a hex editor and string search)
• Find pics/movies/docs/web-mail and log positions for review. Alternatively, review them immediately for specific issues
• If applicable, use steganography detection software to detect hidden data in images and music.
• Analyze browser cookies for connection to specific sites or Internet activity
• Analyse e-mail records for connection to specific sites or Internet activity
• Investigate files in slack space (deleted from the File Allocation Tables but not physically from the disk)

3. All incriminating evidence (context dependent) are to be logged with original timestamps and with appropriate presentation (screenshots, text dumps, audio recording)

This is by no means a definitive and final tutorial. Shortinfosec will follow-up with excersises and a demo dump for the readers to dissect in the comfort of their own home.

Talkback and comments are most welcome