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.

1. First, create a strings file from the .img file. srch_strings _a -t d sample.img > sample.asc
   
2. 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.
   
3. 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:"
4. Now, I usually check that the block number in step has data. I run a blkcat sample.img original_block_number (from step 3)
   
5. 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
   
6. To ensure that the inode number points to blocks: istat sample.img inode_num.
7. Finally, we can use the inode number to pull the file name that we're looking for. Run: ffind sample.img inode_num
   

These steps will find the file name that contains a particular string that we pulled out of the string file.

edit 10-5-09: I went back through these directions and they were written pretty badly. So, I've updated them for clarity.

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.

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.

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:

• 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

2. When the drive is in the machine, but it can't be removed:

• 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

3. Live Acquisition

• 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.