It's one of my favorite shows; and I've seen every episode. But, I think the actions of Mr. Nick Stokes and Ray Langston might not hold up in court. Not grabbing volatile memory might be forgiven and certainly isn't a crime. But it certainly might have garnered more evidence. However, actually using the computer while imaging the drive seems to me to be a bit more egregious.
I know, it's just a show. And the plot has to move to fit the hour timeslot. But still. It's a little tough to watch the obvious gaffes. I'm sure the other forensic professions see the issues particular to their discipline.
Thursday, October 8, 2009
Monday, October 5, 2009
Updated post on icat
I just updated the post on file name finding with icat. I'm working on a practical assignment and I went back over my post, and can't figure out what I was writing. So, the post has been updated for clarity.
Tuesday, September 22, 2009
Crawling out from the paperwork to check the air
It's been a busy couple of weeks. I went on a testing trip that I truly consider a boondoggle. I think the company sent us on the trip just to maximize revenue for the overall project. The problem is, I think the client called the company's bluff. As such, they've demanded a ton of documentation; not that we don't have the data, but the client isn't the most helpful. That, and I'm finishing up documentation for a system we tested almost three months ago. But, there's light at the end of the tunnel, I've already got my next project; a nice big, fat juicy LAN to test.
On the forensics front, I'm in the middle of recovering mp3s from a friend's external usb drive that had crashed. I'm using foremost, and getting great results. I'll write that up when I'm finished.
On the forensics front, I'm in the middle of recovering mp3s from a friend's external usb drive that had crashed. I'm using foremost, and getting great results. I'll write that up when I'm finished.
Wednesday, September 9, 2009
Using Sleuthkit tools to recover pictures from a camera's flash card
We finished discussing the Sleuthkit tools in class the other week, and had an exercise to reinforce the concepts. A little while ago, I had a friend ask me if I could recover images from their camera's flash card. After completing the discussion on the Sleuthkit tools, I thought I would give it a whirl.
First, I imaged the card; it was two gigs, and easily fit on on my external evidence drive. (My first imaging attempt didn't go so well, I imaged if=/dev/sdf...I should have imaged if=/dev/sdf1. The file system type was unknown until I re-imaged it. The card is using a fat file system. And by the way, to know that I didn't image properly the first time, I ran an fsstat on the image, and fsstat couldn't determine the fie system type. I knew I was cooking with gas when I re-imaged properly the second time and fsstat showed fat, and the pertinent info on the file system.)
After imaging, I ran: sorter -h -s -m K: -d /images/windowsforensics/sorter /mnt/usb/flashcard.img
Bingo! I had about 185 images returned. My friend was only looking for 25 or so, and was thrilled to gt them all back.
First, I imaged the card; it was two gigs, and easily fit on on my external evidence drive. (My first imaging attempt didn't go so well, I imaged if=/dev/sdf...I should have imaged if=/dev/sdf1. The file system type was unknown until I re-imaged it. The card is using a fat file system. And by the way, to know that I didn't image properly the first time, I ran an fsstat on the image, and fsstat couldn't determine the fie system type. I knew I was cooking with gas when I re-imaged properly the second time and fsstat showed fat, and the pertinent info on the file system.)
After imaging, I ran: sorter -h -s -m K: -d /images/windowsforensics/sorter /mnt/usb/flashcard.img
Bingo! I had about 185 images returned. My friend was only looking for 25 or so, and was thrilled to gt them all back.
Tuesday, August 25, 2009
Using strings to find file names
This is just another mental note, detailing a manual process to find a filename when you have a string. It's yet another great process, albeit manual. We've just gotten to Autopsy in the class, and the automatic process of performing the tasks that we've learned about doing manually. I kind of like these manual processes because you really see what's going on at each step. I'm sure I'll change my tune once I have to perform the tasks on a huge hard drive with many many files. Anyway.
For this example, I'm using "MYGROUP" as the string that we're searching for. "sample.img" is the dd image that was created of the filesystem.
edit 10-5-09: I went back through these directions and they were written pretty badly. So, I've updated them for clarity.
For this example, I'm using "MYGROUP" as the
- First, create a strings file from the .img file. srch_strings _a -t d sample.img > sample.asc
- Now, we can grep for a particular string. grep MYGROUP sample.asc This will return the offset of the string. There could be more than one return, so you may have to run the process a couple of times; steps 3-7 would be repeated.
- Now we need to find the original_block_number. To do this, we divide the offset from step two by the default blocksize of the filesystem. To find the default blocksize, I run the following command: fsstat sample.img | grep "Block Size:"
- Now, I usually check that the block number in step has data. I run a blkcat sample.img
original_block_number (from step 3) - To find the inode_num that the block number from step three points to: ifind sample.img -d
original_block_number. The result will be the inode_num - To ensure that the inode number points to blocks: istat sample.img
- Finally, we can use the inode number to pull the file name that we're looking for. Run: ffind sample.img
inode_num
edit 10-5-09: I went back through these directions and they were written pretty badly. So, I've updated them for clarity.
Thursday, August 20, 2009
Using icat to recover delted files
We had a great class the other night, and one topic we discussed really jumped out at me. So, I'm organizing my notes in hopes that a) I don't forget what I learned, and b) these notes can help someone else. We were discussing methodologies to return data from the file system at the logical and physical layers. Here's one set of procedures we followed:
1. Image the hard drive.
2. Create a time line (a two-step process):
a. For unix, run: fls -m / -r /path/to/file.img > /path/to/file.bodyfile
For windows, run: fls -m C: -r /path/to/file.img > /path/to/file.bodyfile
b. run mactime -d -b /path/to/file.bodyfile > /path/to/timeline_name.csv
(I'm partial to the "-d" switch to produce a time line that's in a csv format.)
3. As you search through the time line, you can look for orphaned and deleted fils. Note the ones you would like to potentially recover, and be sure to jot down the inodes associated with those files.
4. Run icat, passing the inode number: icat -r /path/to/file.img [inode_number] > unknown_file
5. run: file unknown_file -- this will give the file type (if it is determinable)
6. run: strings unknown_file -- this will show any of the readable strings in the file (send to a file if you need to do further investigation, or there is a lot of data.)
Cool, cool stuff. icat is part of The Sleuthkit.
1. Image the hard drive.
2. Create a time line (a two-step process):
a. For unix, run: fls -m / -r /path/to/file.img > /path/to/file.bodyfile
For windows, run: fls -m C: -r /path/to/file.img > /path/to/file.bodyfile
b. run mactime -d -b /path/to/file.bodyfile > /path/to/timeline_name.csv
(I'm partial to the "-d" switch to produce a time line that's in a csv format.)
3. As you search through the time line, you can look for orphaned and deleted fils. Note the ones you would like to potentially recover, and be sure to jot down the inodes associated with those files.
4. Run icat, passing the inode number: icat -r /path/to/file.img [inode_number] > unknown_file
5. run: file unknown_file -- this will give the file type (if it is determinable)
6. run: strings unknown_file -- this will show any of the readable strings in the file (send to a file if you need to do further investigation, or there is a lot of data.)
Cool, cool stuff. icat is part of The Sleuthkit.
Thursday, August 13, 2009
Windows Vista - and Gold Disks, part 2
Our ACA sent out a note that the Army had pushed forward with Vista. All systems are supposed to upgrade to Vista by December 2009. Any systems that have machines that are not AT LEAST Vista (or do not have a waiver) could be disconnected. Of course, I foresee many systems experiencing problems with the idiosyncrasies of Vista, but that’s another story. Further, any system that has accreditation will not need re-accreditation, according to the ACA.
The latest version of the Gold Disk came out in June. I noticed on my last certification trip that it checked for many many more controls than the prior version of Gold Disk that I used. A little inspection of the documentation revealed that Gold Disk now works on Vista. And, the latest Vista checklist states that the Gold Disk is acceptable to use when testing a Vista machine. So, I plopped it in my laptop to see what would turn up. Note that my laptop is configured to corporate policy, and is not even close to DoD STIGs.
Gold Disk completed its analysis successfully, and I created the XML to take a look at what it found, and what was not reviewed. As expected, there were plenty of findings, along with configurations that were correctly set. I was most interested in what was not reviewed as those tests would be the pain points when out testing other systems; those tests would have to be performed manually. Following are some of the checks that were "Not Reviewed" when I ran the Gold Disk. Where practical, I’ll attempt to list what the Vista Checklist has to say. The checklist is Version 6, Release 1.12, Dated 26 June 2009.
· Physical Security – V0001070 - manual
· Shared Accounts – V0001072 - manual
· System Recovery backups - V0001076 – manual
· Registry Key Auditing - V0001088 – unable to determine why this check was not performed
· Legal Notice is Not Configured – V0001089 – I’m guessing this because the setting is in the Security Policy > Local Policy that GD did not pick it up. (We have a banner on our laptops, it may be set by a Group Policy.)
· Security Configuration Tools – V0001128 – Again, I think this has to do with Group Policy.
· Strong Password Filtering – V0001131 – I think GD has not been updated for this check, as it seems like a registry check. (And the checklist still references the fact that GD doesn’t work on Vista.)
· Access To Windows Event Logs – V0001137 – I’m not sure why this is not checked.
· Users With Administrative Privilege – V0001140 – obvious.
· Enable Strong Password Filtering – V0001150 – I think this is like V0001089.
· Service Object Permission – V0002371 – looks manual. I thought it was checked on XP systems, though.
· Disable Reversible Password Encryption – V0002372 – Local security policy
· Unencrypted Remote Access – V0002908 – looks like a manual check
· Anonymous SID/Name Translation – V0003337 – manual security policy check
· Anonymous Access to Named Pipes – V0003338 – manual security policy check. (Though I thought this worked in XP, so it must be a Vista security change.)
· Remotely Accessible Registry Paths – V0003339 – manual registry inspection
· Anonymous Access To Network Shares – V0003340 – manual security policy check.
· Internet Information System (IIS) – V0003347 – manual check
· Security Related Software Patches – V0003828 – manual check
· Remotely Accessible Registry Paths and Sub Paths – V0004443 – manual registry check
· DCOM – Authorization Level – V0006825 – need the command line to check
· DCOM – RunAs Value – V0006830 – manual registry check
· Audit Configuration – V0006850 – manual security policy check
· A boat load of IAVMs
· Backup Administrator’s Account – V0014224 – manual
· Administrator Account Password Changes – V0014225 – policy check
· Hide Computer – V0014231 – I’m not sure why this isn’t checked. I know MSS checks are performed against XP.
· IPSec Exemptions – V0014232 – see above
· A whole bunch of UAC settings – these require a manual security policy check
· There were a bunch of Desktop Application checks – that seem to be related to Vista’s security architecture.
· A bunch of Windows Firewall checks were not reviewed. These look like registry settings. I don’t know if the Gold Disk couldn’t get access to the registry key, or if it is because our laptops use a 3rd party firewall.
· There were some other findings, but as I look at them, I’m not sure if it is Vista, or my specific machine.
As I test more machines, I’ll get a handle on why some of the findings are manual checks.
The latest version of the Gold Disk came out in June. I noticed on my last certification trip that it checked for many many more controls than the prior version of Gold Disk that I used. A little inspection of the documentation revealed that Gold Disk now works on Vista. And, the latest Vista checklist states that the Gold Disk is acceptable to use when testing a Vista machine. So, I plopped it in my laptop to see what would turn up. Note that my laptop is configured to corporate policy, and is not even close to DoD STIGs.
Gold Disk completed its analysis successfully, and I created the XML to take a look at what it found, and what was not reviewed. As expected, there were plenty of findings, along with configurations that were correctly set. I was most interested in what was not reviewed as those tests would be the pain points when out testing other systems; those tests would have to be performed manually. Following are some of the checks that were "Not Reviewed" when I ran the Gold Disk. Where practical, I’ll attempt to list what the Vista Checklist has to say. The checklist is Version 6, Release 1.12, Dated 26 June 2009.
· Physical Security – V0001070 - manual
· Shared Accounts – V0001072 - manual
· System Recovery backups - V0001076 – manual
· Registry Key Auditing - V0001088 – unable to determine why this check was not performed
· Legal Notice is Not Configured – V0001089 – I’m guessing this because the setting is in the Security Policy > Local Policy that GD did not pick it up. (We have a banner on our laptops, it may be set by a Group Policy.)
· Security Configuration Tools – V0001128 – Again, I think this has to do with Group Policy.
· Strong Password Filtering – V0001131 – I think GD has not been updated for this check, as it seems like a registry check. (And the checklist still references the fact that GD doesn’t work on Vista.)
· Access To Windows Event Logs – V0001137 – I’m not sure why this is not checked.
· Users With Administrative Privilege – V0001140 – obvious.
· Enable Strong Password Filtering – V0001150 – I think this is like V0001089.
· Service Object Permission – V0002371 – looks manual. I thought it was checked on XP systems, though.
· Disable Reversible Password Encryption – V0002372 – Local security policy
· Unencrypted Remote Access – V0002908 – looks like a manual check
· Anonymous SID/Name Translation – V0003337 – manual security policy check
· Anonymous Access to Named Pipes – V0003338 – manual security policy check. (Though I thought this worked in XP, so it must be a Vista security change.)
· Remotely Accessible Registry Paths – V0003339 – manual registry inspection
· Anonymous Access To Network Shares – V0003340 – manual security policy check.
· Internet Information System (IIS) – V0003347 – manual check
· Security Related Software Patches – V0003828 – manual check
· Remotely Accessible Registry Paths and Sub Paths – V0004443 – manual registry check
· DCOM – Authorization Level – V0006825 – need the command line to check
· DCOM – RunAs Value – V0006830 – manual registry check
· Audit Configuration – V0006850 – manual security policy check
· A boat load of IAVMs
· Backup Administrator’s Account – V0014224 – manual
· Administrator Account Password Changes – V0014225 – policy check
· Hide Computer – V0014231 – I’m not sure why this isn’t checked. I know MSS checks are performed against XP.
· IPSec Exemptions – V0014232 – see above
· A whole bunch of UAC settings – these require a manual security policy check
· There were a bunch of Desktop Application checks – that seem to be related to Vista’s security architecture.
· A bunch of Windows Firewall checks were not reviewed. These look like registry settings. I don’t know if the Gold Disk couldn’t get access to the registry key, or if it is because our laptops use a 3rd party firewall.
· There were some other findings, but as I look at them, I’m not sure if it is Vista, or my specific machine.
As I test more machines, I’ll get a handle on why some of the findings are manual checks.
Wednesday, August 12, 2009
How To Image a hard drive
This is mostly a mental note for myself. Personally, it's one of the questions I was most looking forward to having answered in the SANS 508 class; and it was finally answered. I have other questions, but this one I was most looking forward to.
As I've learned in class, there seems to be three basic scenarios: A drive is handed to you to image (dead acquisition,) using Helix (you need to copy a drive from a machine but you can't take the drive,) and finally imaging a drive where the machine can not be shut down (live acquisition.)
1. When the drive is handed to you:
As I've learned in class, there seems to be three basic scenarios: A drive is handed to you to image (dead acquisition,) using Helix (you need to copy a drive from a machine but you can't take the drive,) and finally imaging a drive where the machine can not be shut down (live acquisition.)
1. When the drive is handed to you:
- Attach drive to the system. Use SIFT or Helix. Use write-blocker if available.
- run fdisk -l to see new (acquisition) drive
- attach external USB drive as target drive
- run fdisk -l to see usb drive
- mkdir /mnt/usb
- mount USB to filesystem (ntfs-3g -o force /dev/"usbdrive" /mnt/usb)
- dc3dd if=/dev/"acquistion drive" of=/mnt/usb/name.img progress=on hash=md5 hashlog=/mnt/usb/name.md5
- Know that the system is going to be rebooted and there will be loss of volatile evidence
- Boot the machine with Helix
- run fdisk -l to see the acquisition drive
- attch external USB drive as a target drive
- run fdisk -l to see the usb drive
- mkdir /mnt/usb
- mount USB to filesystem (ntfs-3g -o force /dev/"usbdrive" /mnt/usb)
- dc3dd if=/dev/"acquistion drive" of=/mnt/usb/name.img progress=on hash=md5 hashlog=/mnt/usb/name.md5
- This will be a snapshot of the system, because the system will stay up
- Will be able to gather volatile evidence first
- Attach USB to system
- You will have to have a copy of dc3dd to run (cd, usb)
- dc3dd if=/dev/"acquistion drive" of=/mnt/usb/name.img progress=on hash=md5 hashlog=/mnt/usb/name.md5
Acceptable Use Policy and Privacy
We discussed the issue that I've linked to (below) in my 508 class last night. The gist of the story is that a woman is suing her company. As she was about to leave her company, she used her personal web-based email to communicate with her lawyer. The company recovered her emails in a forensic investigation. She claimed that the company's acceptable use policy said that reasonable use of the internet was ok, and as such, she should have been afforded privacy. An appellate court agreed with her.
Here's the story.
I brought this up at the company I'm working at, and the CIO said "no way, couldn't happen." I think companies need to take a hard look at their acceptable use policies if this appellate court decision is going to stand. Further, if it does, look for casual, reasonable use of the internet to disappear; which probably won't sit well with employees.
Here's the story.
I brought this up at the company I'm working at, and the CIO said "no way, couldn't happen." I think companies need to take a hard look at their acceptable use policies if this appellate court decision is going to stand. Further, if it does, look for casual, reasonable use of the internet to disappear; which probably won't sit well with employees.
Monday, July 27, 2009
Getting into a Gold Disk-locked laptop and scanning a laptop not set up with network connectivity
Back from testing. It was a packed couple of days, and we worked in a pretty tough environment. Anyway, we had two sets of laptops that Retina could not scan, as it couldn't connect to the registry; even when we had the correct admin user name and password.
In the first case, we needed to scan two laptops that were not connected to the network. We had crossover cables, and we tried running the scans; each time though, we couldn't connect to the registry. My co-worker came up with a good trick. Because the laptops were in a workgroup, we were able to run the network setup. From there we ran the wizard, picked home network, but didn't actually set up anything. The process installs and starts the "server" service which allows the sharing of the drive. After that, we were able to run our scan and connect to the registry.
The second case presented an interesting problem. Again, we couldn't connect to the registry. However, this time, a little investigating turned up the cause. The client had run Gold Disk on the machine, and immediately clicked "remediate" when Gold Disk was finished. Yep, they locked up the box something good. Logging in to the machine from the network was not possible. To fix this, we went to Control Panel -> Administrative Tools -> Local Policies -> Security Options. From there, allow network login access.
In the first case, we needed to scan two laptops that were not connected to the network. We had crossover cables, and we tried running the scans; each time though, we couldn't connect to the registry. My co-worker came up with a good trick. Because the laptops were in a workgroup, we were able to run the network setup. From there we ran the wizard, picked home network, but didn't actually set up anything. The process installs and starts the "server" service which allows the sharing of the drive. After that, we were able to run our scan and connect to the registry.
The second case presented an interesting problem. Again, we couldn't connect to the registry. However, this time, a little investigating turned up the cause. The client had run Gold Disk on the machine, and immediately clicked "remediate" when Gold Disk was finished. Yep, they locked up the box something good. Logging in to the machine from the network was not possible. To fix this, we went to Control Panel -> Administrative Tools -> Local Policies -> Security Options. From there, allow network login access.
Subscribe to:
Posts (Atom)
