Our data acquisition.
A couple of different categories of data acquisition.
It's either live or dead.
Live is volatile acquisition, dead is static acquisition.
Live involves collecting data from a
system that is powered on, and that's generally memory resident information.
Dead acquisition, collecting data from a system that is powered off.
Data acquisition, use of established methods to extract
electronically stored informationfrom suspect computer.
You want to be comprehensive and thorough.
You want to do both a live and a dead acquisition.
Approach the system, do a ramp dump,
collect volatile information, record the state of running applications on the
screen, shut it down, extract the hard drive, run an image of the fixed disk.
So a complete or thorough acquisition is going to involve both live and dead.
A live acquisition involves collecting volatile data from a live system.
So again, this can be live and interactive.
This can be current configuration, running
state, date and time, current system up time, running processes, logged in users,
DLs in use, shared libraries, swap files, temp files, and network data, things like
routing tables, ARP Cache, net configurations, and network connections.
You can also get a lot of that from a RAM dump.
So whether you're interacting with the system live or you're interacting with a
RAM dump using volatility Python script, something like that, same concept.
The volatility Python script driven version is a lot
slower than a live system since you're parcing the entire image file, running a
PS list process listing or whatever it is that you're running.
With collecting evidence, an investigator needs to follow.
Here's our order of volatility.
I mentioned earlier, we're going to see a slide for this.
The order volatility describes what you
collect first, what's most at risk of being lost.
First on the list is registers and cash, anything resident memory.
Second is routing table, process table, kernel statistics and memory.
Third is temporary system files.
Fourth is disk or other storage media.
Fifth is remote logging and monitoring
data that is relevant to the system in question.
Six is physical configuration and network
topology, and seven is archival media, which is least likely to change over time.
That is your order of collection.
Again, this all is laid out at the time you respond, the incident response,
because you've got an idea of what you're investigating.
You do have a plan of attack, that's your procedural document, which again gives us
consistent, repeatable results if applied correctly the same way every time.
Data acquisition.
Defined as the acquisition of data from a suspect machine that's powered off.
We actually already did one of these when
I did the D D command and imaged my SDB to SDC.
That's a perfect example of a data acquisition.
Usually involves acquiring data from
storage devices, hard drives, DVD drives, USB, etc.
Examples of static data, emails, Word documents, web activity spreadsheets,
Slack space, unallocated drive space, and various deleted files.
All right, so this is a great example
of dead acquisition data that's been mounted in an analysis utility.
For each of these,
I've got volume information, I've got file and folder structure.
These are all statically acquired images
of the drive and they're parsed much the same way as you just parse the
local file system with lots of analysis utilities for searching for useful data.
Again, come back for the CHFI for the full autopsy discussion.
This is a great example of statically acquired data or dead data.
Logical acquisition.
Types of data acquisition.
Logical, allows the investigator to
capture only files or file types of interest to the case.
For example, if I know that my smoking gun
is an email that I'm looking for in my investigation, I would only need an
Outlook PST file because no other files are going to contain emails.
If I'm not 100 % certain your best course of action is always to do a full bitwise
image of the suspect machine, and again, that's a full block device imaging
physical image, and your Outlook PST file will be a part of that process.
But again, the idea here is you don't miss
anything by miscalculating what you need to require.
There may be something there you don't know about that's advantageous.
Full bit wise, image always grabs everything.
As far as acquisition, similar to logical,
when you're not collecting everything on the drive, collects fragments of
unallocated data allowing used investigators to acquire deleted files.
Use this method when inspection of the entire drive is not required.
Again, you're collecting some data, but not all on the drive.
A gain, the investigation type warrants
the response, but it's always best to do a full bitwise image of the entire drive.
However, that's not always practical, especially in very large drive volumes.
So logical and sparse are a couple of
options if it's impractical to do a physical bitwise image.
Then we're back to the BitS tream Imaging Discussion.
Bits tream disk image to File is
the acquisition of an entire disk written to an image file, period.
It's the same data, but it's written to a file versus written directly to a drive.
Bits tream Disk to Disk is a disk to disk
is a disk to disk copy, and that's exactly what I showed you in the demo.
We did a disk to disk D D image, which is a raw image from SDB to SDC.
I could have also done a bit image, speaking of which,
I could have also just done it through an output file.
Ef equals image.
Dd, for example.
Same process, but I'm out of space, so that's going to be a bit of an issue.
But you can just specify your destination to be a device or a file.
All right, determine the best data acquisition method.
The investigator needs to identify the
best acquisition method suitable for the investigation.
Situations would include the size of the suspect's drive, time required to acquire
the image, and whether the investigator can retain the drive.
An example, in the case, the original
evidence drive needs to be returned to the owner.
As the case and discovery demand for civil
litigation, check with the requ whether logical acquisition is acceptable.
If not, you may have to go back to the requ.
Investigators need to acquire only the
data that's intended to be acquired to be required, and we just talked about that
with the bit wise or the distant image or logical or sparse.
Sorry.
Step two, select the data acquisition tool.
Now there's mandatory and optional
requirements or optional options for your acquisition tools.
At the very least, bare minimum, the tool should not change the original content.
Absolutely, that would be tampered with the evidence.
The tool should log IO errors in an accessible and readable form, including
the type of error and the location of the error.
The tool should have the ability to pass scientific and peer review.
Really important, we've mentioned that before.
If the tool does not stand up to
scientific peer review scrutiny, it's not considered to be a reliable tool.
Results must be repeatable and verifiable by a third party if necessary.
We've mentioned that several times.
The tool should alert the user if the source is larger than the destination.
Warning, you're about to image to a device that doesn't have the necessary space.
Are you sure you want to attempt that?
The tool should create a bit stream copy
of the original content when there are no errors in accessing the source media.
The tool should create a qualified bit
stream copy, which is defined as a duplicate except in identified areas of
the bit stream where IO errors occur while accessing the source media.
Those are the mandatory requirements.
Optional requirements would be things like
functionality to log case metadata, different types of formats, etc.
But at the very least, you need to satisfy those mandatory requirements.
Dd, great option for that.
Number three is sanitize the target media.
Our investigators must properly sanitize the target media in order to eliminate any
prior data residing on it before it's used for collecting forensic data.
It needs to be sanitized.
You should have it zeroed out and your best course of action is to always use
brand new shrink wrap drives that have never been used before.
However, that can be a little bit expensive.
Depending on the formality of the
investigation, you might reuse your target media.
Zeroization is a great option for that.
We do have drive sanitizing utilities.
We've got high speed wipinging utilities,
which a lot of times, they get a just zeroization.
As a matter of fact, you can use a dd
command to specify input File equals Dev0 and write zeroes to the target media.
All right, post investigation, dispose
this media by following the same standards.
Minigate the risk of unauthorized
disclosure of information and ensures confidentiality.
There's a variety of standards for data standardization.
You have a Russian standard, German, a couple of different Americans, DODs, and
NIST's SP 800 tag 88, which is put out by National Institute of Standardization of
Technology, which puts out lots of special publications relating to lots of things.
That one in particular is proper media standardization.
Step 4, acquire Volatile Data.
Volatile data acquisition involves
collecting data that's lost when the computer shut down or restarted.
Usually corresponds to running processes,
logged on users, registries, DLLs, clipboard data, open files, etc.
Forensic tools like B elkaSoft LiveRam capture and PS tools can be used to
extract the entire contents of the computer's volatility memory.
In the lab, you're going to be using a utility called B elkaSoft LiveRam capture,
which is a real straightforward, easy to use utility.
There are other memory acquisition tools, D&D can do it with the right syntax.
It saves the image files in a.mem format.
Then, of course, you've got the parsing of
that using volatility, which you can use PS tools against volatility.
All right, step five, enable write protection on the evidence medium.
Necessary to enable write protection so you don't taint the original evidence.
Using write blockers to preserve and protect the evidence contained on it.
Hardware write blockers physically block the write lead.
Software write blockers will do it through the driver.
You can also mount the device as read only.
However, on a Windows system, just by
installing the drive, it wants to write a disk signature.
You want to be sure that a write blocker
is employed, whether that's logical or it's physical.
Write blocks, write commands.
Hardware Write Blockers used, install it in line with the device.
If the software Write Blocker is used, boot the system with the examiner
controlled operating system, activate the write protection.
Step six, acquire non volatility data.
After you've acquired volatility data,
shut the system down and image the hard drive.
Non volatility data acquired both live
acquisition and dead acquisition involves acquiring data from a hard disk.
The system can be shut down or you can image it from a live box.
Depending on the scenario and then pulling
a drive out and hooking it up to a high speed duplicator is definitely the most
time efficient process because you have a high speed disk to disk transfer.
No significant difference between the amount of data acquired from a hard disk
between the live and dead acquisition methods.
Live acquisition of a hard disk is performed, what I do with it here,
by using remote acquisition tools like NetCAT, bootable CDs or USBs like Kine.
Here's an example of a acquisition tool.
I got this off of Amazon for like 12 bucks.
It's the Kine Linux forensics distribution on a thumb drive, and I just popped this
into a system and I use it to boot to a RAM drive version of Kine,
and then I can do DEDs against local drives or hook in a USB device.
Now, I mentioned recently I hard powered down and corrupted a hard drive.
That drive is actually showing as locked.
I could still see the file system.
I booted to this guy and I did a D D
zeroization on it and at least got the file structure off.
I'm still having some issues with the write blocking, though.
I fear I may have corrupted that disk
entirely, but I was able to do some analysis using the boot disk.
This is a great acquisition tool and analysis tool.
It's a Linux Distro with all sorts of file system utilities.
Pretty cool. Got it off of Amazon for like 12 bucks.
All right, live acquisitions.
Then step six, acquire non volatility data using Windows Forensic Workstation.
The example they're giving you here is Access Data's FTK Imager, which you're
going to be, again, everybody all together now, playing with in the lab.
The access data FTK Imager is pretty widely used.
Disk Imaging Program, which can preview recoverable data from a disk of any kind,
also create copies, forensic images of that data.
It can do it, drives, folders, and DVD drives, and the whole nine yards.
Step 7 is to plan for contingency.
Investigators, every so often, your tool
is not going to work and you're not ready for it.
It's like, It works all the time.
What's going on now?
So you should have a contingency plan.
The last time I ran into an issue, I was doing an acquisition on a Raid disk
subsystem, doing a forensic investigation on a Microsoft Exchange server, and my
imaging tool wouldn't see the drive, plain and simple.
I was using actually the
Helix boot disk, which is like the Kine disk, and the Adepto UI that uses the D&D
command on the back end, wasn't able to see the drive.
Basically, the driver wasn't loaded in the
kernel for that particular distro, and I wasn't able to see the drive.
My contingency plan was I fired up Clone
Zillow instead, which was another boot disk.
It worked just great.
But you don't run that very often.
Usually, your tools behave as expected.
In that case, it was a driver issue, but it was unexpected.
Then I was immediately up and running with
another tool, got the acquisition done, was able to proceed with the analysis.
Plan for contingency.
You need to plan for contingencies like
hardware software doesn't work or failure occurs during an acquisition.
Hard disk data acquisitions.
You want to create at least two images of
the digital evidence collected in order to preserve it.
If one copy becomes corrupt, then use the other copy.
Let's lay this out here.
Here's the original.
Original drive.
I create a forensic copy of the original drive.
That's my copy.
I authenticate it, MD5 or Shaw, MD5 or Shaw.
When that checks out, this guy gets sealed up, tagged in
bag, and then I create a copy of the copy.
The copy is also MD5ed to ensure it's a copy.
Then I may actually create a working copy off that just to have a backup copy.
But you never work on the original ever.
You do create a copy, but you want to make
sure you got a copy of that copy just in case you corrupt the copy because you
never want to have to go back to the original and reimagine it.
You create a library control copy, you
extract a working copy from that, that's the one you work on.
If this gets screwed up, you make another copy.
Always keeping the original library copy unaltered and intact.
And again, you authenticate each copy and
document that process so that you can prove through your
documentation that it was a verbatim image of the original drive.
All right, so imaging tools.
Dd, Access Data, FTK Imager, CloneZilla, R Drive IMAGE, Norton Ghost.
There's tons of imaging utilities.
The hardware acquisition tool.
Consider using a hardware acquisition tool like U Fed ultimate or IM Soul.
Again, the benefit to hardware acquisitions are speed.
You have drive to drive duplicators.
You pop one drive on one side, it's got a right blocker built in.
You pop the other drive on the other side,
crank it up to 11, and just it starts slamming data transfers.
Faster than your typical system busses.
The U Fed that they're mentioning here is...
Cellebrite is one of the reference
standards for mobile acquisitions and forensics.
That U Fed is a hardware device capable of acquiring 1,400 different handsets,
different Android versions, and so forth for seller acquisitions.
So hardware can go a long way in optimizing the acquisition process.
But of course, you can always do it
through a USB connected drive and say a live OS.
So again, this Kain Distro.
I could boot my suspect system with Kain, which is forensically configured.
So this is configured to not touch that drive.
I would plug in a USB drive to the same system.
I could do a disk to disk copy of the original without taking it out.
So again, that's a RAM drive, resident
image or a live disk, which everything loads to memory, stays off the local
subsystem and definitely is one of your acquisition options.
All right, drive decryption. Yeah.
So if you got to encrypt the drive, that's going to be a problem.
You can acquire it, you can analyze it,
you can definitely copy and encrypt the data.
You just can't decode it on the receiving end.
So if you've got an encrypted drive, be prepared to deal with encrypted drives
that need the user to provide the decryption key for decrypting.
Microsoft BitLocker is included with Vista
or Lator, which is anything post XP days, which requires a BitLocker key.
So that actually can be entered into the
forensics utility, but you got to know it to begin with.
So without that bit locker key, encrypted data remains encrypted.
Now, there are tools for breaking encryption for different devices, but
without that encryption key, you're stuck with trying to crack the encryption key,
which again can be a very time consuming process.
So mobile devices also have drive encryption.
If you remember several years ago, there
was that big court terrorist case where the FBI was on all over Apple to give up
the backdoor decryption keys, the iPhone, and they wouldn't do it.
Turns out they didn't need it.
They used gray box for one of those
utilities instead, and that got into the phone.
There's a variety of tools over the years
that are built for cracking mobile device encryption.
It really depends on the version of the
phone and the handset and the OS as far as which tool to use.
Always loved the ElcomSoft tools.
Paraband's got a lot of great tools and oxygen.
I would do oxygen a while.
Oxygen, phone manager, and a bunch of others, celebrate, etc.
Step eight, validate the data acquisition.
Again, that is a hash, digital fingerprint of the file.
Remember, when you run a hash, you always
get the same output every time with the same input.
This is used for an integrity check.
We've already looked at it.
The algorithms used to produce hash values are CRC 32, MD5, Shaw 1, Shaw 256.
You shouldn't rely on CRC 32.
Md5 is fine.
Md5, though, is not collision resistant.
Is it possible that you could generate hashes from an original and a forensic
copy, have the hashes match up, and have it actually not be the same data?
Yeah, it's possible. Is it probable?
Not by a long shot.
You'll still consider an MD5 authentication to be reliable, but best
case scenarios are Shaw 1s or higher or Shaw 256.
All right, the tools for validating data acquisitions in Windows, Windows doesn't
have native command line utilities like MD5 some and Shaw some that you would see
in Linux, but it does come with the power shell utility, which has a get file hash
commandlet, which allows you to communicate that, compute the hash value
for the evidence file using the specified algorithm.
All right, so Git FileHash, pretty straightforward.
Specify the file.
There's also the CertU til utility, which
would do it as well, which is an older function on your Windows systems.
Then you've got a ton of different hash
calculators out there for performing hash calculation.
You've seen examples of hash calculators in your cryptography labs.
If it's an MD5 calculation, it's an MD5 calculation.
Anything that runs that MD5 check will be performing the same math.
It's just implemented differently via the tool.