Home
> Computer forensics > EnCase Workflow Guidelines
EnCase Workflow Guidelines
In several Guidance classes, I’ve heard fellow students ask “Can you suggest a standard workflow for using EnCase?” The exact workflow will vary from case to case, but I’ve put together one possible workflow with some help from other contributors to the Forensic Focus forum. Please bear in mind that this is a guideline, a suggestion, just one possible way to work through a case using EnCase. You should clearly understand what each of these steps entails and adjust the workflow to suit your style, your written processes, and the case you are working on.
- Create case – Ensure that you have all relevant information – custodians, clients, case name, etc.
- Change storage paths as appropriate. I set everything to go to a volume or folder dedicated to the case.
- Save All.
- Add evidence – E01, LEFs, loose files, etc. Each time you add evidence, you should consider rerunning several of the following steps.
- Confirm disk geometry, sector count, partitions. You’re checking to see if everything is accounted for. There may be hidden partitions, for example.
- Run Partition Finder if indicated
- Run Recover Deleted Folders
- Search case – hash and signature analysis. You will probably repeat this each time you add new evidence.
- Run File Mounter – recursive, not persistent, create LEF, add LEF to case.
- Run Case Processor -> File Finder. Export results, add back in as LEF.
- Search case – hash and signature analysis.
- Search for encrypted or protected files. Address as appropriate.
- Extract registry hives. This can happen at any point really and they’ll be fed to RegRipper.
- Index case.
Depending on the case:
- Analyze LNK files and INFO2 records
- Extract browser history and carve browser history from unallocated
- Parse the event logs into a CSV format.
Other tasks performed outside of EnCase:
- Mount image and scan for viruses. Use several different products and never assume that they’re 100% accurate.
- Mount image and run triage tool(s) against it
- Run image in LiveView or VFC to see system as user experienced it
- Run RegRipper and RipXP against registry hives
- Run MFT Ripper against an extracted MFT
- etc, etc, etc
Categories: Computer forensics
Integriography: A Journal of Broken Locks, Ethics, and Computer Forensics 
This kind of perspective is very beneficial, just wanted to say thanks.
As we also learn in class never publish/document your forensic “process”. It could be used against you in court such as “Why didn’t you follow step #X when examining my client’s computer?” Oh, you forgot a step? What else did you forget?
A couple of things to consider:
1) There is a difference between guidelines and processes. Guidelines are a suggested, rather than required, approach. Write up your processes as guidelines and allow for some latitude. (You’ll note that I said “guidelines” and “exact process will vary from case to case.” in my article.)
2) If you deviate from your guidelines, or process, document why you did so. Hashes don’t always match but, if you can explain why they differ and why your analysis is still valid, you should carry the day. The same holds true for documented processes.
3) If you don’t document your processes, how do you teach new staff? How do you ensure that your team conducts investigations in a similar manner? How do remind yourself to do everything on a process that you use infrequently and isn’t committed to memory?
4) There are some things you really should do in a particular order. For example, if you run File Mounter, add the resulting LEF back to the case, and don’t do a search to recalculate the hashes and signatures then any efforts to use hash and signature values will fail on the files in the LEF in the future.
In which class were you taught never to publish/document your process?