Category Archives: Evidence Acquisition

RSA 2010 – Digital Forensic Analyst Notebook

0
Filed under Digital Forensic Law, Evidence Acquisition, Evidence Analysis, Incident Response, Malware Analysis, Memory Analysis, USB Device Analysis, eDiscovery

The RSA Security Conference was held this week in San Francisco. The conference is jammed packed with sessions, whiteboarding events, demonstrations, and more.  Here are my observations and interview sound bites. I was covering RSA San Francisco 2010 as a forensic analyst and co-host of The CyberJungle, a weekly live news and talk program on security, privacy, and the law.

Digital forensics is still the non-sexy topic at RSA Security. There were no dedicated forensics tracks for this conference.  But computer forensics were mentioned now and then in session talks, although many times by the audience more than the speakers.

Smart Grid Forensics
For example, there was an industry panel on electric smart grid security standards. The panelists in this session did not have forensics on their agenda, but a member of the audience did. Gerry Brown is an independent forensics consultant. He was an audience member in this session, and took to the mic to question whether the industry is preparing properly for incident response and evidence gathering in the event of a smart-grid related electrical disruption. I caught up with him right after the session, You can listen to that audio interview here, it’s about 7 minutes long.

Christopher Brown did a purely forensic talk on Thursday afternoon. He talked about the challenges of relying upon system time stamps for evidence collection. His talk was very informative, and he is a good speaker. Unfortunately, there were less than 30 people were attending the session. The forensics industry might still have a long way to go in making this area of infosec “sexy.”  Brown wrote a book on forensic evidence collection, entitled, “Computer Evidence: Collection & Preservation.” Here is a guy that might shed some light on the issues that Gerry Brown brought up. After Chris’ talk, I caught up with him to get his take on the concern that Gerry Brown raised in the smart grid session about the challenges in forensic evidence collection as it relates to smart grid incident response. You can listen to that audio interview here, it’s about 7 minutes long.

Mariposa Botnet and Related Forensics
During the RSA Conference there was a major arrest and take down on a large EU botnet, called “Mariposa.” Panda Security worked with Spanish LE, and researchers at Georgia Tech on incident response, and information gathering for the arrests.  The attackers used malware that is very difficult to detect. I interviewed Pedro Bustamante from Panda Security about the very stealthy nature of the malware used by the attackers. Pedro speculated that he might be giving an in-depth talk at a future conference about this botnet and the related attacks. You can listen to that audio interview here, and this interview is about 8 minutes long.

Cloud Computing Forensics
There was a dedicated legal session related to Cloud Computing, and the issues of forensics and ediscovery were a topic of that session. Too often executive decision-makers will rush in to buy a Cloud Computing solution, focusing only on the monthly savings. The members of this panel strongly recommended that legal and forensics specialists should be part of the pre-purchase process.  Some of the issues that are not often brought up until after the data has moved into the cloud include data de-duplication.  When a cloud provider de-dupes, he wipes out the original meta data. This could have a huge negative impact in the event of litigation. Many contracts do not have provisions to spell out mutually agreed upon procedures for incident response for data in the cloud. Too often these items come up long after the contracts are signed, giving the customer much less leverage in getting the vendor to change procedures.

Cryptome Spying guides as a Digital Forensic Resource

3
Filed under Computer Forensics, Digital Forensic Law, Evidence Acquisition, eDiscovery

Since December 2009, Cryptome.org has been publishing the legal spying guides from a variety of services and Service Providers. There was publicity this past week when the Microsoft Legal Spying Guide was posted and a DMCA takedown notice was placed against Cryptome domain and its owner John Young. The DMCA restraint has since been lifted. This blog entry is not intended to defend or decry the DMCA notice. It is intended to provide Digital Forensic investigators a resource for appropriate contact and process logic contained in the Legal Spy guides published.

These documents were created to assist Law enforcement and appropriate investigators of what can be provided and the methodology for request. The guides were generally considered confidential in nature when distributed. It is not my intent to break confidentiality of the source or creator. It is intended to assist in digital forensic discovery. Many of these documents are strictly intended for Law Enforcement and not corporate investigations. This should not deter the reader in my opinion using the contact information provided.

The published documents contain appropriate process for requests and available detail from the source. Some links listed are example documents or public record examples of evidence gathered.  The guides/handbooks were originally created and provided for informational purposes to all law enforcement and legal requests.

The following sources have been referenced and published from Cryptome.org:

Microsofthttp://cryptome.org//isp-spy/microsoft-spy.zip
Paypalhttp://cryptome.org/isp-spy/paypal-spy.zip
MySpacehttp://cryptome.org/isp-spy/myspace-spy.pdf
Facebook  – http://cryptome.org/isp-spy/comcast-spy.pdf
AOLhttp://cryptome.org/isp-spy/aol-spy.pdf
Skypehttp://cryptome.org/isp-spy/skype-spy.pdf
Cox Communicationshttp://cryptome.org/isp-spy/cox-spy.pdf
Ninghttp://cryptome.org/isp-spy/ning-spy.pdf
MyYearbookhttp://cryptome.org/isp-spy/myyearbook-spy.pdf
Stickamhttp://cryptome.org/isp-spy/stickam-spy.pdf
USPS Requests http://cryptome.org/isp-spy/usps-spy.pdf / http://cryptome.org/isp-spy/usps-spy2.pdf
Ciscohttp://cryptome.org/isp-spy/cisco-spy.pdf
3GPPhttp://cryptome.org/3gpp/3gpp-spy.htm
ATT - http://cryptome.org/isp-spy/att-spy-doc-01.pdf  / http://cryptome.org/isp-spy/att-spy-doc-02.zip 

Verizonhttp://cryptome.org/isp-spy/verizon-spy.pdf
Sprint CALEA Deliveryhttp://cryptome.org/isp-spy/sprint-spy2.pdf
Sprinthttp://cryptome.org/isp-spy/sprint-spy.zip
Nextelhttp://cryptome.org/isp-spy/nextel-spy.pdf
Voicestreamhttp://cryptome.org/isp-spy/voicestream-spy.zip
Yahoohttp://cryptome.org/isp-spy/yahoo-spy.pdf
SBC-Ameritechhttp://cryptome.org/isp-spy/sbc-ameritech-spy.pdf
Ameritechhttp://cryptome.org/isp-spy/ameritech-spy.pdf
SBC-LEAhttp://cryptome.org/isp-spy/ameritech-spy.pdf
Cingularhttp://cryptome.org/isp-spy/cingular-spy.pdf
Crickethttp://cryptome.org/isp-spy/cricket-spy.pdf
Pactelhttp://cryptome.org/isp-spy/pactel-spy.pdf
GTEhttp://cryptome.org/isp-spy/gte-spy.pdf

There are three key elements found in each guide. These assist the investigator when conducting an authorized investigation and they are:

  1. Contact address, Phone number, email address and hours of  access for the Provider/Corporate Security
  2. What detail can and cannot be delivered by the provider. This includes retention duration of the data available.
  3. Description on the process and requirements for making a request. The capability of the provider response depends upon the authority of the request. A Statute or Judicial request is handled differently than a Law Enforcement inquiry as is a corporation’s legal request.

It should be understood; these requests do not come without cost. The cost to process a request may exceed $10,000 depending upon request and duration. Some requests cost much less. There are some providers that do not appear to have a charge associated with the service.

In many of the guides, there is also a template or form to use when making a request. It is useful to know these details when conducting an investigation.  The same logic of Time Based Security can be applied to responding to evidence acquisition. The clock is ticking, the longer the delay, the greater the potential for lost evidence.

Steven is the senior member of an IT Security team for a Bio-Pharma company. He has presented to a variety audiences including SANS, Midwest Consolidated Security Forum and various local chapters of HTCIA and ISACA. His current focus is Certificate Management, Encryption and Incident Response. With a science degree unrelated to IT, Steven has over 20 years in Information Technology with the past 13 years in Security. He has earned among the various vendor certificates, his CISSP (#3700), CISA (#153869) as well as GIAC G7799 (#151) GSNA (2849) Silver and GCFA (#18) gold certifications.

Tableau Imager: First Look

4
Filed under Computer Forensics, Evidence Acquisition

I haven’t paid much attention to write blocking technology for the last few years.  As long as I was able to validate that the device worked as expected and it had a high speed connection (Firewire 800 / eSATA), I was happy.  But I spent some time with Tableau’s founder, Robert Botchek at the end of last year and he impressed upon me how much room for innovation still exists in the write-blocker market.  We are up against some major hurdles in the digital forensics world that are rapidly changing the way we do business.  With 2TB drives on the shelves, the decision to take a full forensic image is no longer obvious.   If a user has to be without their computer or a server has to be down for 2 days, that significantly changes the equation.  That’s why I was excited to see Tableau enter the imaging software space with Tableau Imager (TIM). 

Michael Cloppert recently made an excellent plea for innovation in the IDS industry in his post, Detection, Bandwidth and Moore’s Law.    A key takeaway was that processor speed has reached a plateau and new advances are now occurring through number of cores per die.  In many cases, software must be re-written to take advantage of multi-core processors.  TIM takes advantage of this shift by parallelizing the actions that occur during the imaging process.  Thus actions like hashing and compression can be performed in parallel with the imaging process, having little effect on the total imaging time.

The current feature set is limited, but it includes many of the features you want in a dedicated imaging product.  For those of you who have used Tableau’s Disk Monitor software, you will notice that TIM has incorporated it into the product.

Tableau Imager Disk Monitor

Tableau Imager Disk Monitor

TIM provides a well thought out view of the available devices.  Double-clicking on a device gives a Disk Information page that can be exported for report inclusion.  The HPA / DCO information section is particularly helpful.

Tableau Imager Disk Details

Tableau Imager Disk Details

Double clicking in the Acquisition Queue brings up a graphical display of the current imaging process.  The graphic is more than just eye candy.  It is apparently designed to provide real-time feedback about any choke points that may be slowing the acquisition.  I was unable to test this, which is likely due to using a relatively new quad-core system.

Tableau Imager Acquisition Status

Tableau Imager Acquisition Status

My initial testing results were impressive, with 2.5 GB/min sustained speeds using 5400rpm SATA drives, while creating MD5 and SHA1 hashes and employing maximum compression.  This was 30-40% faster than other imaging software I tested using the same hardware.  When I performed the same acquisition with no hashing or compression, the acquisition speed was the same, indicating that the tasks are indeed being peformed in parallel.  Imaging speeds should be much faster using 7200 or 10000 rpm drives.  For all my tests, I used the Tableau T35e bridge from the SANS FOR408 Computer Forensic Essentials course.   TIM won’t beat most handheld imagers, but the speed is excellent for a digital forensic workstation based acquisition.

There are some limitations with this product.  Most notably, it will only image drives connected using a Tableau bridge / write blocker.  Additionally, v1.0 of the product only performs physical acquisitions.  TIM is available here for free.

Chad Tilbury, GCFA, has spent over ten years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases.   He currently teaches FOR408 Computer Forensic Essentials and FOR508 Computer Forensic Investigations and Incident Response for the SANS Institute.

Internet Evidence Finder (IEF): interview with Jad Saliba of JADSoftware.com

1
Filed under Computer Forensics, Evidence Acquisition

Editor’s note: Brad Garnett recently had an opportunity to interview Jad Saliba, of JADSoftware about how he got started in computer forensics and about some of his company’s products. Please note that JADSoftware has offered a discount to readers, see the details below.

Q: Jad, Take a minute to introduce yourself and give us some insight into your background. How did you get involved in computer forensics and software development?

I’ve been involved in software programming on and off for a long time, going back to my teenage years. I’ve always had an interest in system tools and figuring out what’s going on behind the scenes in a computer. I went to college and studied computer networking and programming, and worked in the industry for a short while before getting into law enforcement, which is another passion of mine. I didn’t want anyone to know about my computer skills when I first got hired! But a few years later I was diagnosed with cancer and after being off for a year fighting with that, I started to think that something a little less stressful and with a better schedule would be a good thing for my family and my health. I approached the head of the Technological Crimes Unit, Eugene Silva, who needed an extra hand and graciously brought me into the unit and has kept me there so far!

Q: You have developed several software tools that can assist computer forensic professionals during the analysis phase of a forensic exam. Tools like Internet Evidence Finder (IEF), FChat (FCT), Encrypted Disk Detector (EDD), and Facebook® JPG Finder (FJF) are all great for the forensic examiner’s toolkit. We are going to focus on IEF. Explain how IEF is used during media analysis and its capabilities/limitations.

JADSoftware's Internet Evidence Finder

JADSoftware's Internet Evidence Finder

IEF is simply a tool that searches for Internet related artifacts on a disk or in a file and parses them out into a readable format. It currently supports 19 different types of artifacts, including things like Facebook chat, Yahoo! Messenger chat, MySpace chat, Hotmail and Yahoo webmail, Limewire searches, and many more. IEF can be run in a number of different ways. You can run it directly against a drive that is connected via a write-blocker, or on a mounted image (mounted by Encase’s PDE or a program like Mount Image Pro). If there are specific files or areas you want to search (pagefile.sys/hiberfil.sys files, or unallocated clusters), you could copy these out and point IEF to the specific files or to a folder containing files. As IEF searches the specified item(s), the results are saved to CSV/TSV report files or individual files, depending on the format of the artifact. Statistics are displayed during the search to keep you updated on the progress.

Q: There have been several updates recently to IEF. What are some future enhancements and capabilities in development for IEF?

I hope to add things that include greatly improved reporting features, an option to search unallocated space only, Unicode support, more searches, and a portable version of IEF that could be run on a live system. There’s a long list that I hope to start tackling in the near future.

Q: What programming language did you use when you wrote IEF and why?

I use a mix of Visual Basic and other code, depending on the process. I try to use as many low level system calls as possible to make things run as quickly as the hardware and/or medium will allow. I’m comfortable with Visual Basic and it enables me to easily put my ideas into code while keeping the processes manageable, optimized and running fast.

Q: Do you have any future plans for IEF to be a cross-platform application (i.e. Linux, Mac)?

I don’t have any plans for a cross platform application at this time. However, IEF can search drives formatted in Linux and Mac systems if they are mounted on or directly connected to a Windows system. The drive will appear as a PhysicalDrive(#) without a drive letter and IEF can search that raw drive (point it to the PhysicalDrive# that appears).

Q: You stated that there are plans for developing a portable edition of IEF to be used forensically on a live system. As live forensic acquisitions continue to grow, this would be a great tool for the incident responder/forensic analyst. Explain.

I think IEF is very well geared towards memory dump files created by tools such as ManTech’s MDD and HBGary’s Fastdump PRO. A lot of the testing I do when adding support for new artifacts is with memory dumps. I also have plans for an “IEF Portable” that will run from a thumb drive and could be used with a Windows FE (Forensic Edition) boot disk or other forensic boot disk that would allow IEF to run forensically on the live system. I’m also planning to add a “Quick Search” option for the searches that would only search common areas and things like the pagefile.sys file to give the investigator a quick look or preview of the drive.

Q:  Do you have any additional tools in development that you would like to share with the SANS Computer Forensics blog audience?

I’m currently working on an application that will take a list of URLs (or import URLs from a CSV file, such as an Internet history report file) and then visit each URL, taking “scrolling screenshots” of each page and saving them all to an indexed, easy to browse HTML report. I think it will be useful for preserving or visually displaying a portion of a user’s web browsing history, and to show what they may have seen when they visited those URLs. It would be especially useful in situations where no Internet connection is available, such as courtrooms.

Q: What can the forensic community do to make IEF better? Do you have a mailing list or a way users can submit issues or provide feedback on IEF?

I’m always open to suggestions for new features (although I won’t always be able to make them happen!) and bug reports. I just want IEF to be as easy to use, feature rich, and bug-free as possible. I do have a mailing list that folks can sign up on to receive updates when new programs or releases come out. Comments and suggestions can be sent either through the contact page on my website or directly to my email address, jad-at-jadsoftware-dot-com.

IEF Discount

IEF Discount: use code SANS15 through 2/28/2010

Jadsoftware.com is offering an exclusive 15% discount to SANS Computer Forensic Blog readers when you purchase Internet Evidence Finder (IEF). The coupon will be good for the month of February 2010 only. The code is “SANS15″. To claim your discount, go to the IEF purchase page (http://www.jadsoftware.com/go/?page_id=214) and enter the code in the “Enter discount code” box just above the Buy Now button and click “GO”.

Mr. Brad Garnett, CCE, GCFA is a law enforcement officer specializing in computer forensics. You can follow Brad on Twitter @bgarnett17

Helix 3 Pro: First Impressions

4
Filed under Computer Forensics, Evidence Acquisition, Evidence Analysis, Incident Response, Linux IR, Memory Analysis, Registry Analysis, Windows IR

I have used several versions of Helix over the recent years.  I enjoy the tool set and recommend it to forensics colleagues, sysadmins, and even family members.

Quite a substantial ruckus was raised this year when e-fense announced that Helix 3 would no longer be free to download.  Instead, would-be users must pay to register as a forum user to get access to Helix 3 Pro updates for a year.

I took the plunge and purchased my forum membership.  Here are the first things I noticed:

  • Some of the highlights…
    • The forum allows access to the Helix 3 software the member applies a registration token.
    • After adding the token, I was able to download not only Helix 3 Pro, but also Helix 3, and contributed tools.
    • Helix 3 Pro is really nothing like the 1.8 and 1.9 versions that came before it.  Although it still provides a bootable live CD as well as executables that can be run in Windows in Linux, the interfaces for all the modes of use have been made more consistent and seamless.  Also, a Mac OS X set of tools have been added.
    • The Helix 3 Pro CD also provides a set of cell phone forensics tools (that I will cover in a follow-on posting).
    • One of e-fense’s goals with the Helix 3 release was to provide a forensics tool that did not touch the host computer in any way.  I have not tried to verify this yet, although I intend to do so soon.
  • And the lowlights…
    • On my Dell D630 laptop (and few other systems), the boot process generated a number of errors and — in some cases — would not detect a graphical interface mode correctly, leaving me with an unusable Helix environment.
    • The majority of the tools that made previous versions of Helix useful are just completely gone.  This is apparently done so that the Helix Pro 3 image can be trusted.  I spoke to a sales representative at e-fense who told me that several customers were using Helix 3 Pro in environments where open source software of questionable origins is, well, frowned upon.
    • Static binaries formerly found on the Helix 1.x CDs are now separate downloads.  They are still available through the Helix forums.

This is the first in a series of blog postings I plan to publish on Helix 3 Pro.  Please post comments if there are specific tools or features of the LiveCD you would like me to cover.

John Jarocki, GCFA Silver #2161, is an Information Security Analyst specializing in intrusion detection, forensics, and malware analysis. He also holds GCIA, GCIH, GCFW and GSEC certifications and is the Treasurer of NM InfraGard.  John recently co-authored a controversial paper on using LiveCDs to mitigate online banking risks.

Mounting Images Using Alternate Superblocks (Follow-Up)

0
Filed under Computer Forensics, Evidence Acquisition, Evidence Analysis

Hal Pomeranz, Deer Run Associates

Several months ago, I blogged about using alternate superblocks to fake out the ext3 drivers so you could mount file system images read-only, even if they were needing journal recovery.  However, due to recent changes in the ext file system driver the method I describe in my posting is no longer sufficient.  Happily, there’s a quick work-around.

Let’s try the solution from the end of my previous posting under a more recent Linux kernel:

# mount -o loop,ro,sb=131072 dev_sda2.dd /mnt
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
 missing codepage or helper program, or other error
 In some cases useful info is found in syslog - try
 dmesg | tail  or so

This looks like the original error output we got when using the primary superblock.  Looking at the relevant dmesg output we see something different, however:

[163135.527484] JBD: Ignoring recovery information on journal
[163135.795917] Buffer I/O error on device loop0, logical block 0
[163135.795931] lost page write due to I/O error on loop0
[163135.795944] Buffer I/O error on device loop0, logical block 1
[163135.795949] lost page write due to I/O error on loop0
[163135.795958] Buffer I/O error on device loop0, logical block 2
[163135.795963] lost page write due to I/O error on loop0
[163135.795973] Buffer I/O error on device loop0, logical block 3
[163135.795977] lost page write due to I/O error on loop0
[163135.795986] Buffer I/O error on device loop0, logical block 18
[163135.795991] lost page write due to I/O error on loop0
[163135.795999] Buffer I/O error on device loop0, logical block 32
[163135.796034] lost page write due to I/O error on loop0
[163135.796232] Buffer I/O error on device loop0, logical block 73
[163135.796238] lost page write due to I/O error on loop0
[163135.796248] Buffer I/O error on device loop0, logical block 74
[163135.796253] lost page write due to I/O error on loop0
[163135.796261] Buffer I/O error on device loop0, logical block 94
[163135.796267] lost page write due to I/O error on loop0
[163135.796275] Buffer I/O error on device loop0, logical block 96
[163135.796280] lost page write due to I/O error on loop0
[163135.796516] JBD: recovery failed
[163135.796520] EXT3-fs: error loading journal.

It would appear that even though we’re using an alternate superblock that’s marked as not requiring journal recovery, the ext file system driver is still finding the uncompleted journal entries and trying to apply them.  This is arguably “more correct” behavior than the old driver used, but it doesn’t help us very much.

The simple work-around is to tell the ext file system driver to ignore the journal by forcing the file system to be mounted as ext2:

# mount -t ext2 -o loop,ro,sb=131072 dev_sda2.dd /mnt
# ls /mnt
bin   dev  home    lib         mnt  proc  sbin  usr
boot  etc  initrd  lost+found  opt  root  tmp   var

Excellent!  With this small modification our trick is working again.  Hurrah!

You might well wonder what happens if you just try to mount our image as ext2 without using the alternate superblock.  Unfortunately, simply mounting as ext2 is not sufficient because the primary superblock is still marked as needing journal recovery.  Though I wonder why this flag should be relevant to an ext2 file system, it’s enough to prevent the mount from happening.  So the result is that you need to both mount using an alternate superblock and (at least on modern Linux kernels) mount the file system as ext2 to stop the file system driver from looking at the journal.

Hal Pomeranz is an independent IT/Computer Security consultant and a SANS Faculty Fellow.  He actually discovered this problem when attempting to give a live demo in the middle of a class.  Unfortunately, the solution only occurred to him after class was concluded.  This is one of the reasons why being a SANS Instructor can be so… invigorating.

The Failed Hard Drive, the Toaster Oven, and a Little Faith

3
Filed under Computer Forensics, Evidence Acquisition

OK, everyone knows that heat kills electronic components, right?  Never subject any electronic component to heat.  Unless that makes the component work, that is…

Confession is good for the soul, they say, but bad for the reputation.  So I’ll tell the story this way.  You see, there was this “friend of mine” whose hard drive failed.  I mean, it was working fine the night before when I, er, he shut down his computer.  But the next morning he turned it on and all he got was “shicka, shicka, shicka, shicka, shicka,” then a pause, then five more attempts, then five more, and so on until the drive finally said “sorry…” and shut itself off.  Now this guy hasn’t been taking his own advice about backups for a while and – you guessed it – he hadn’t backed up his Quicken off drive since, oh, about December of 2008!

The first attempt was to unplug the power and let the hard drive sit and think about running all day long while he was at work.  One friend told him, “My drive does that all the time.  I just unplug it and plug it back in and it works.”  Sounds good, he thought.  So at the end of the work day, he came back home, plugged it in, held his breath, and powered up.  No joy!  Five more “shickas” and he powered it back off.  Now what?

The next thing, especially when one has theological training, is to have a prayer meeting with one’s wife!  (Seriously.)  He knew it was going to take a miracle at this point to avoid spending an inordinate amount of time and money to get this thing going.  After the prayer meeting, I decided…  ok, no more pretense – I’m the one that hadn’t been practicing what I preach when it comes to backing up…  I decided to try the freezer trick I keep hearing about.  Hadn’t really ever needed it before, but I was getting desperate.  So I put the drive in a zip lock with some silica gel, and stuck the drive in the quick freeze section of my freezer for about 30 minutes or so. 

 

Keep in mind, now, my electronics are good.  The BIOS recognizes and correctly identifies the drive as a 250 GB Western Digital model Wd2500jb-57gvc0.  And remember that I had NO trouble with it up until that morning.  I figured it was worth a shot, although I think Scott Moulton prefers freeze spray to icing down the whole drive.  This has got to work.  Perhaps with a little help from the almighty…  I plug it back in, turn on the computer, and – you guessed it – “shicka” some more.  So I power down.

 

Now, I start thinking – which is a very dangerous thing at times.  Last night when I shut down – when the drive was working just fine – it was warm.  Not cold.  Now, I am trying to get it to run but it is cold, not warm.  Do you see where this is going?

 

I set the toaster oven on about 150 degrees, or so – probably a normal running temp for a lot of devices – and let it warm up.  Then I took the drive and laid it on the rack with the top down and electronics up.  (I didn’t want to cook the circuit board from the bottom element!)  Then I stood by and opened the oven door every 30 seconds or so, and felt the drive with my hand to make sure it wasn’t getting too hot.  I know what a running drive feels like, so I figured I should be able to get it to the right temp without burning the casserole, if you know what I mean. 

After a few minutes, I determined that it felt just like a warm, running drive.  So I pulled it from the oven, took it to the computer, and let it sit for a couple of minutes to equalize.  I knew at that point that, while the outside was crisp, the inside was still warm and gooey.  After equalization of the heat, I plugged it in, powered up, and it ran PERFECTLY!  I was able to use Helix to image the entire 250GB drive over to a new 500GB drive without a single error!

So, here is my theory – If we are working with a drive that:

  • Has not given us a problem before
  • Its electronics are known to be good
  • Was running fine when it was warm and it powered down fine
  • Hasn’t been backed up since Christmas of last year
  • Desperately needs data recovery!

We may try this procedure with the following caveats –

  1. Preheat the oven
  2. Use bake, not toast or broil
  3. Turn the drive upside down when you put it on the rack
  4. Make certain that it does not get too hot!  (Too bad we can’t insert a meat thermometer)  It should never be hot enough to burn you!
  5. Let it sit and equalize the heat before you try plugging it in
  6. DISCLAIMER:  Neither the author of this blog, nor anyone the entire GCFA community or at SANS will be responsible if you end up with a burnt “casserole” and render your drive even worse than it was before you started!
  7. It might work

Please don’t tell my GCFA instructor Rob Lee, or SANS instructor Scott Moulton, that I suggested this.  I don’t want them to think I’ve totally lost my marbles!!!

By the way, Quicken is alive and well.  Oh, and I have 4 copies now of my data files.  (Just in case)  And, by the other way, what I always told my customers was:  a) “If you have done enough work that you would not want to have to do it over, it is time to make a backup,” and b) “You will never fully appreciate backups until you have a catastrophic failure.”  (And that isn’t “If” but “When” you have a catastrophe!)

OK, my soul is better now.  My reputation is probably back where it belongs.  And I have to thank God for the inspiration to even try this.  (For those who do not “believe,” I have to remind you that there are no atheists in foxholes.  At least, that is what I have always heard, although there are differing opinions on the topic.  For me, this computer stuff can be a real battle, sometimes.  I welcome all the help I can get!)

J. Michael Butler, GCFA Gold #00056 GSEC EnCE CISA, is an Information Security Consultant employed by a fortune 500 application service provider who processes approximately half of the $5 trillion of residential mortgage debt in the US. He is a certified computer forensics specialist. In addition, he authored the enterprise wide security incident management plan and information security policies for his corporation. Butler has authored a number of blogs and white papers.  He can be reached at jmbutler_1 at hotmail dot com.

Best Practices In Digital Evidence Collection

6
Filed under Computer Forensics, Evidence Acquisition, Memory Analysis

Evidence handling procedures are evolving

Evidence handling is clearly one of the most important aspects in the expanding field of computer forensics. The never-ending innovation in technologies tends to keep best practices in constant flux in effort to meet industry needs. One of the more recent shifts in evidence handling has been the shift away from simply “pulling the plug” as a first step in evidence collection to the adoption of methodologies to acquire evidence “Live” from a suspect computer.

The need for changes in digital evidence collection are being driven by the rapidly changing computing environment:

  • Applications are installed from removable media such as a USB stick and are then virtualized in RAM without a trace on the hard disk
  • Root kits hide within process undetected by the underlying operating system and when using local tools (binaries) – you must analyze memory with trusted binaries
  • Malware is fully RAM resident with no trace of existence on the hard disk
  • Users regularly utilize covert / hidden encrypted files or partitions – areas of the hard drive to hide evidence
  • Popular web browsers offer the user the ability to cover their tracks – log files of user activity are created but deleted when the browser is closed
  • Web 2.0 continues to change the landscape with web based email, blogs, wiki’s and twitter extending storage of user actions / communications beyond the traditional hard disk found on the users machine.

An Introduction to Live Digital Evidence Collection

Effectively Live forensics provides for the collection of digital evidence in an order of collection that is actually based on the life expectancy of the evidence in question. Simply put in all likelihood perhaps the most important evidence to be gathered in digital evidence collection today and for the foreseeable future exists only in the form of the volatile data contained within the computers RAM.

Order of volatility of digital evidence

  1. CPU, cache and register content
  2. Routing table, ARP cache, process table, kernel statistics
  3. Memory
  4. Temporary file system / swap space
  5. Data on hard disk
  6. Remotely logged data
  7. Data contained on archival media

An accepted best practice in digital evidence collection – modified to incorporate live volatile data collection.

Stand Alone Home Computer

For proper evidence preservation, follow these procedures in order (Do not use the computer or search for evidence)

  1. Photograph the computer and scene
  2. If the computer is off do not turn it on
  3. If the computer is on photograph the screen
  4. Collect live data – start with RAM image (Live Response locally or remotely via F-Response) and then collect other live data “as required” such as network connection state, logged on users, currently executing processes etc.
  5. If hard disk encryption detected (using a tool like Zero-View) such as full disk encryption i.e. PGP Disk – collect “logical image” of hard disk using dd.exe, Helix – locally or remotely via F-Response
  6. Unplug the power cord from the back of the tower – If the computer is a laptop and does not shut down when the cord is removed then remove the battery
  7. Diagram and label all cords
  8. Document all device model numbers and serial numbers
  9. Disconnect all cords and devices
  10. Check for HPA then image hard drives using a write blocker, Helix or a hardware imager
  11. Package all components (using anti-static evidence bags)
  12. Seize all additional storage media (create respective images and place original devices in anti-static evidence bags)
  13. Keep all media away from magnets, radio transmitters and other potentially damaging elements
    Collect instruction manuals, documentation and notes
  14. Document all steps used in the seizure
  • Note: * If computer is x64 the author recommends collecting the image of RAM using HBGary FastDump Pro

Live forensics of volatile computer evidence is not necessarily a new or recent development

The author’s first exposure to live forensics in digital evidence collection was nearly 10 years ago during his initial SANS GIAC Certified Forensic Analysis (GCFA) forensics training http://computer-forensics.sans.org/course/computer-forensics-investigation-and-response-98-1. The course included several hands on labs that allowed students to become familiar with tools such as the Windows Forensic Toolkit (WFT) http://www.foolmoon.net/security/ that automated the collection of the volatile data from the subject PC in a forensically sound manner:

  • Only utilizes trusted / know binaries
  • Minimized impact on the subject PC – any impact documented
  • Extensive logging
  • Creates hashes for all tools utilized as well as all data collected

Hence even a decade ago computer forensics evidence collection training went well beyond being limited to simply imaging a hard drive. It included the training necessary to perform the collection of “Live” evidence such as that found in RAM in a forensically sound manner. As an example the methodologies taught at SANS as part of the GCFA training enabled the forensics investigator to include the volatility of all data as part of their consideration in the planning for the evidence collection process. Hence using the training from SANS you were effectively enabled to collect all available and relevant evidence. Starting of course with that data which is most volatile first. Not simply focusing on the limited evidence available on the computer hard drive.

Live forensics resources

There are several other options that have become available that the author has become familiar with to acquire volatile digital evidence – live data including creating an image of RAM in a forensically sound manner (in no specific order):

In closing:

In digital evidence collection today live forensics has become a necessity. Among many forensic professionals both in law enforcement and private practice it has long been recognized that the tradition of first pulling the plug on a PC under examination is an outdated and overly conservative approach that can destroy valuable evidence. Our ability to reliability collect volatile evidence in a forensically sound manner has effectively rendered our legacy best practice of “pulling the plug” as an obsolete methodology.

Decrypting a PointSec Encrypted Drive Using Live View, VMWare, and Helix

4
Filed under Computer Forensics, Drive Encryption, Evidence Acquisition, Evidence Analysis

Doing it the HARD way!

Perhaps you remember my previous blog on EnCase and PointSec, which included my plea for Guidance Software and CheckPoint to work together to create a seamless way to decrypt drives without having to go through 20 or 30 steps to get there.  I even wrote, out of desperation, A Case for Decryption of the Original, because it would save time consuming steps and not change the data relevant to an investigation.

Time for an update.  As noted in my last blog on decrypting the original, VMWare no longer recognizes a raw disk as a valid disk image.  Images have to be converted before VMWare will recognize them.

 Here is a new and “improved” method that will result in a COMPLETE decrypted image without changing the original.  It is more painful because more steps are involved, but it works.  (Today).  That being said, I STILL want PointSec, now called “End Point Security,” to work with Guidance to create a driver that could be used to directly access the disk image and decrypt it in EnCase.  This can’t be rocket science, right?  Let me add an encrypted image to the case, key in a password, and access the data.

In the mean time, gather your tools.  You will need the dcfldd for Windows, Live View application, VMWare Server, and Helix for imaging.  (Twice).

  1. Use Helix or your other favorite method to acquire a raw image of the drive to be decrypted.  (There is an open source version of Helix you can download for free, or you can purchase Helix Pro in order to have support, if your prefer.)  [Watch for my upcoming blog on using dcfldd to acquire a raw image.]
  2. Use Live View to convert the raw image to a VMDK file.  (You will have to have the correct versions of VMWare to read the VMDK.  Live View will inform you what version of VMWare you should be running.)
  3. Acquire the PointSec recovery file from the administrator.  (This whole process assumes that you have the administrator ID and password for an administrative install of PointSec.  If you don’t have that, you are reduced to a manual brute force attack.  Good luck!)
  4. Using the PointSec recovery file, create Recovery Media.  (Believe it or not, you need a real floppy disk to do this.  Can’t just create a raw floppy image.  Go figure.)
  5. Create a raw image of the floppy disk in a file on the Windows hard drive using the following command:
    dcfldd if=\\.\A: of=filename.img   
    (requires you have dcfldd installed – available from sourceforge.com
    If you use linux, refer to the floppy drive device (if=/dev/fd0 or as appropriate for your system) as the input file instead of the above syntax.)
  6. Copy the resulting floppy image to your VMWare server where you intend to decrypt the image.
  7. Open VMWare
  8. Select the VM created by Live View, but do NOT start the machine.  (Note that you will not have to create a new virtual machine.  Live View handles all that.  But also note that Live View creates a snapshot and other files as well, which cannot be read directly into EnCase Forensic.  That is why we must do the final acquisition with Helix in this process.)
  9. Add a floppy drive to the VM configuration and select the image created above as the floppy virtual drive.  Make sure it will “Connect on Power On” so that the machine will boot to the floppy

10.  Edit the CD Rom settings and set it to use an ISO image.  Point to a copy of the Helix ISO image.  (This is for acquiring the decrypted drive later, but will not be used for the decryption step.)

11.  Start the Virtual Machine – it will boot to the floppy image.

12.  Enter the requested PointSec administrator credentials and start the decrypt process.  The VMDK image will be decrypted.

13.  Once you have entered the credentials, the program begins decrypting the hard drive image, posting a % complete message as it goes.

14.  Once decrypted, reboot the VM

15.  Hit escape ONE TIME during boot to get Boot Menu.  (If you hit escape too many times, VMWare will blow by the boot menu, but not to worry, because we have left the floppy image set up as the boot drive.  That way the decrypted image will not boot and will, therefore, remain unchanged for maintaining Chain of Custody.)

16.  Select CD-Rom from the boot menu to boot to the Helix CD-Rom.

17.  Run Helix from the CD.

18.  Insert a USB drive with enough spare space to receive the image from the “target” machine.  You will mount it later.  Helix is able to mount NTFS in read/write mode, so your portable drive can be formatted using NTFS.

19.  Once Helix has booted up, use the VMWare toolbar option:  VM/Removable Devices/USB Devices to select the USB drive for writing the acquired decrypted image.

20.  Open a Terminal Session by clicking on the terminal icon in the Helix tool bar.

21.  Execute the following command in order to get root prompt:  sudo su –

22.  Execute the following command in order to determine drive designations:  fdisk –l   [note that is dash lower case L, not I or 1]

23.  Once the USB drive has been added to the VM, if it is formatted using NTFS, use the following command to mount the drive:
mount –t ntfs-3g /dev/sdx1 /media/sdx1 –o force  
(substitute correct letter for x based on the results of your fdisk –l listing)

24.  Create a directory on the USB drive to receive the image.

25.  Change to the directory you just created.

26.  Execute the following command in order to record disk parameters for the case:  fdisk –l > fdisk.txt

27.  Use the following command to acquire the image:
dcfldd if=/dev/sdx of=filename.img conv=noerror,sync hash=md5 hashlog=filename.img.md5

28.  Once completed, for the record, do the following command to save the history of commands into file:
history > history.txt, then save the mount config in case anyone asks about that with:
mount > mount.txt

29.  Now you have a raw, decrypted image that can be read into EnCase and properly acquired for analysis.  Using this method, the original disk is untouched, and the only change to the disk image is that it was decrypted.  This preserves proper Chain of Custody and avoids contamination of the evidence.

 

Whew, that was way too painful.  In my next blog, I will share a method of “slaving” the target drive so that it can be acquired directly into EnCase with the hard disk left in its original state.  Still not as easy as it ought to be, but much easier than the VMWare method.  The only caveat is that the “Slave” method will allow us to image the decrypted partition(s), but will not allow decryption of the entire hard drive.  So at some point, it may be necessary to use the method in this post, not the “Slave” method.

 J. Michael Butler, GCFA Gold #00056, is an Information Security Consultant employed by a fortune 500 application service provider who processes approximately half of the $5 trillion of residential mortgage debt in the US. He is a certified computer forensics specialist. In addition, he authored the enterprise wide security incident management plan and information security policies for his corporation. He can be reached at jmbutler_1 at hotmail dot com.

Acquiring Data from Windows Mobile Devices

5
Filed under Computer Forensics, Evidence Acquisition, Mobile Device Forensics

During the debut of SEC563 Mobile Device Forensics last week, Eugene Libster from ManTech brought to my attention the open source itsutils package for extracting from Windows Mobile devices. Components of this package, psdread and pdocread, can acquire more data from Windows Mobile devices than many commercial forensic tools, but there are several issues that forensic practitioners need to understand before using these utilities on an evidentiary device. 
 

First, acquiring data using these utilities creates files on the device, necessarily overwriting data. Specifically, an executable file named “itsutils.dll” is copied onto the device, and an error log “itsutils.log” is created on the device. Second, these tools acquire data through a hardware abstraction layer that does not provide direct access to flash memory on the device. Therefore, these utilities do not acquire a complete physical duplicate of flash memory on Windows Mobile devices. 

 

sec563_4_528x90

 

Acquisition of Windows Mobile devices using both pdocread and psdread are described below. The itsutils package requires ActiveSync to be installed on the acquisition system in order to connect with the device, and the Windows Mobile operating system on the target device must be configured to permit unsigned programs to run. To configure a Windows Mobile 6 device to run unsigned code, add the Registry value “HKLM/Security/Policies/Policies/0000101B” with DWORD = 1. The first time a Windows Mobile device is accessed using a component of the itsutils package, a prompt appears on the mobile device requesting that the code be permitted to run, and the message “Copying C:Toolsitsutilsitsutils.dll to WCE:windowsitsutils.dll” is displayed on the command line.

 

Once a Windows Mobile device is connected to an acquisition system, obtaining a copy of storage areas on the device using psdread is relatively straightforward, with a -l option to list the available disks as shown here on an HTC Dash.

 

    C:Toolsitsutils>psdread -l
    C: - VMware Virtual S
    Drive geometry: 0x7a6 cyls, 255 t/cyl 63 s/t 512 b/s -  15.00Gbyte
          disknr=0   fixed disk
    D: - NECVMWar VMware IDE CDR10
    remote disk 1 has 120456 sectors of 512 bytes -  58.82Mbyte
    SerialNr:  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    remote disk 2 has 121464 sectors of 512 bytes -  59.31Mbyte
    SerialNr:  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

     

The first two entries in the above list refer to the local disk and CD-ROM drive of the acquisition system. The two subsequent entries referring to remote disks are the system and data storage areas on the attached HTC Dash Windows Mobile device.  The following command options acquire the storage area that contains the most relevant data from a forensic perspective (remote disk 2 on this HTC Dash), starting at 0 and copying 62189568 bytes (121464 sectors x 512 bytes).

 

    C:Toolsitsutils>psdread -2 0 62189568 E:HTC-Dash-psdread.bin
    remote disk 2 has 121464 sectors of 512 bytes -  59.31Mbyte
    SerialNr:  01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    CopySDCardToFile(remote, 2, 0x0, 0x3b4f000, HTC-Dash-psdread.bin)

     

When psdread does not work with a given Windows Mobile device, it may still be possible to acquire data using pdocread. The pdocread utility only acquires individual partitions and sometimes must rely on the Windows disk API, which may restrict the amount of data that can be acquired. Using pdocread to list the available partitions is shown here.

 

    C:Toolsitsutils>pdocread -l
     58.82M (0x3ad1000) DSK1:
    |           2.09M (0x217400) Part00
    |           3.08M (0x313800) Part01
    |          53.65M (0x35a6000) Part02
     59.31M (0x3b4f000) DSK2:
    |          59.06M (0x3b0e800) Part00
    STRG handles:
    handle cfae68ca 59.06M (0x3b0e800)
    handle 2fb7ba2a 53.65M (0x35a6000)
    handle cfb7ba06  3.08M (0x313800)
    handle 2fb7b9be  2.09M (0x217400)
    <cut for length>

     

The first three partitions under DSK1 are related to the base image on the HTC Dash running Windows Mobile 6: Part00 contains an update kernel that is used when upgrading the operating system, Part01 contains the primary kernel, and Part02 stores the ROM image in LZX compressed format. User created files, Windows Mobile folders and files, and other data of interest in a forensic investigation are stored in the partition listed under DSK2.
 

The partition to be imaged can be specified by name or handle, and we generally prefer to use the unique handle specified with -h option. Using the following command and the handle from the previous command output, we start reading at byte zero and read the full length of the partition, which is 59.06M (0×3b0e800 in hexadecimal). 

 

    C:Toolsitsutils>pdocread -v -w -h 0xcfae68ca 0 0x3b0e800 E:HTC-Dash-Dsk2.raw

     

The -v option provides verbose information during the acquisition process, and the -w option specifies that the Windows disk API be used. Attempts to acquire data without the -w option failed the HTC Dash, but is reported to work on some other Windows Mobile devices like the HTC Touch. Additional options are available to specify the block sizes for reading data from the disk and transferring the data via ActiveSync.
 

The file acquired using pdocread contains a TFAT file system that can be loaded into a tool like TSK or EnCase as a raw image, specifying that it is a FAT volume. Similarly, the file acquired using psdread can be loaded into forensic tools as a disk image. The file system hierarchy on a HTC Dash running Windows Mobile 6 is shown below in EnCase. Although file system entries associated with deleted files can be recovered, the contents were overwritten as shown here for a deleted digital photograph stored in the “My DocumentsMy Pictures” folder.
 

Windows Mobile Volume Viewed Using EnCase

Windows Mobile Volume Viewed Using EnCase

 
The commercial forensic tool XACT can acquire the same information as itsutils from certain Windows Mobile devices as demonstrated through hands-on exercises in the SEC563 Mobile Device Forensics class (register now for NS2009 in San Diego, Sept 16 – 20). However, forensic tools have difficulty parsing the file system of certain Windows Mobile devices, and may not display all files and folders. As we emphasize in the class, processing the same mobile device using different methods and tools can have varied results, and processing similar mobile devices using the same tool can have varied results. Therefore, it is important to perform tool validation by comparing the results of multiple tools and examining data at a low level whenever feasible (e.g., using a hex viewer).