Archive for May, 2011

Firefox Profile Path (Linux)

Posted by:  /  Tags: , , , ,

Author Name

Artifact Name
Firefox Profile Path

Operating System

Location of Firefox profile and related information on a *nix system

File Locations
~/.mozilla/firefox/[random 8 character string].default

Research Links (added by Joe)

Forensic Programs of Use
FoxAnalysis: (added by Joe)

System Install Date (Linux)

Posted by:  /  Tags: , ,  /  Comments: 1

Author Name
Hal Pomeranz

Artifact Name
Linux system install date

Operating System

In general it is rare for any Unix-like operating system to record its
system install date. So you’re left with using other artifacts on the
system as a proxy to deduce the install date.

One of the most popular methods for dating the system install is to
look at the time stamps on the SSH host key files under /etc/ssh.
These files are usually generated via the SSH startup script
(/etc/init.d/sshd or similar) during the first boot of the system,
which typically happens immediately after the system install is

$ ls -l /etc/ssh/ssh_host_*
-rw——- 1 root root 668 Jul 14 2007 /etc/ssh/ssh_host_dsa_key
-rw-r–r– 1 root root 590 Jul 14 2007 /etc/ssh/
-rw——- 1 root root 963 Jul 14 2007 /etc/ssh/ssh_host_key
-rw-r–r– 1 root root 627 Jul 14 2007 /etc/ssh/
-rw——- 1 root root 1675 Jul 14 2007 /etc/ssh/ssh_host_rsa_key
-rw-r–r– 1 root root 382 Jul 14 2007 /etc/ssh/

In the example above, it appears that the system was installed on Jul
14, 2007.

If you’d like to see a finer-grained time stamp, try the “stat”
command on any one of the above files:

$ stat /etc/ssh/ssh_host_key
File: `/etc/ssh/ssh_host_key’
Size: 963 Blocks: 16 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 1837188 Links: 1
Access: (0600/-rw——-) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2009-11-29 09:49:28.000000000 -0800
Modify: 2007-07-14 11:56:52.000000000 -0700
Change: 2007-07-14 11:56:52.000000000 -0700

The modify and change times generally reflect the file creation date
(on EXT4 file systems, there will be a file creation time stamp). The
access time is the last time is the last time the file was read.
Private key files such as /etc/ssh/ssh_host_key are generally only
read by the system SSH daemon, and then only when the daemon is
(re)started. Since the SSH daemon is fairly stable and is rarely
restarted, the last access time often correlates with the last time
the system was booted.

All of the usual caveats about file-based time stamps apply here. It’s
possible, though uncommon, that a site might choose to regenerate
their SSH host keys on a regular basis (doing this causes problems for
users, so it’s not normal practice). Time stamps can be easily
manipulated with programs like “touch”. Certain backup programs may
alter access times on files. Also modern Linux systems generally use
the “relatime” option on file systems by default, making last access
time information untrustworthy.

File Locations

Forensic Programs of Use
ls, stat

Default System Time Zone (Linux)

Posted by:  /  Tags: , ,

Author Name
Hal Pomeranz

Artifact Name
Linux default system time zone

Operating System

f you’re dealing with a live system, the time zone can be observed in
the output of the “date” command:

$ date
Sat May 28 05:07:15 PDT 2011

Look immediately after the time stamp– in this case, the system time
zone is “PDT”.

When investigating a system image, there are two places where the the
system time zone is generally recorded. The first is a configuration
file under /etc such as /etc/timezone on Ubuntu (Debian) Linux or
/etc/sysconfig/clock on Red Had Linux (and derivatives like Fedora and
CentOS). Here’s a sample /etc/sysconfig/clock file:

# The ZONE parameter is only evaluated by system-config-date.
# The timezone of the system is defined by the contents of

The “ZONE” parameter describes the time zone. It is common for Linux
systems to have the administrator configure their time zone by
choosing a well-known city in the given time zone. In this case,
“America/Los_Angeles” is synonymous with the US Pacific time zone, aka

Note the comment at the top of the file. The reason the data in these
configuration files is somewhat untrustworthy is that the applications
on a Linux system generally refer to /etc/localtime for time zone
configuration information. This file need not necessarily match the
setting in the configuration files described above.

The /etc/localtime file itself is in a special binary format that’s
compiled from a text-based configuration file. If you’re doing your
investigation from a Linux system, you can use the “zdump” command to
output the current date in the time zone described by /etc/localtime:

$ zdump /etc/localtime
/etc/localtime Sat May 28 05:16:28 2011 PDT

Again, look immediately after the time stamp for the time zone name.

If you don’t have access to the zdump command for whatever reason, the
analyst can look for matching files in the system time zone directory
under /usr/share/zoneinfo. First compute the MD5 checksum of
/etc/localtime and then look for files matching this checksum under
/usr/share/zoneinfo. Here’s some sample commands for doing this with
the Linux command shell:

$ md5sum /etc/localtime
685e6cae6f7d63e690bf35b955ff4afb /etc/localtime
$ find /usr/share/zoneinfo -type f | xargs md5sum | grep
685e6cae6f7d63e690bf35b955ff4afb /usr/share/zoneinfo/posix/US/Pacific
685e6cae6f7d63e690bf35b955ff4afb /usr/share/zoneinfo/US/Pacific

It’s not uncommon for there to be several matching files under
/usr/share/zoneinfo. Typically these files are links to one another.
In this case the files under the “posix” directory are linked to each
other, and the other two copies are also linked to each other, but all
describe the same time zone.

File Locations

Forensic Programs of Use
find, md5sum, grep

Volume Shadow Copies

Posted by:  /  Tags: , , , ,  /  Comments: 3

Author Name

Artifact Name
Volume Shadow Copies

Artifact/Program Version
Windows 7

This method allows Encase users to explore the contents of Volume
Shadow Copies. As yet I have only tested this on a Windows 7×64
machine, I can not say how effective it will be on other systems.

Most of this method originates from the paper on the
website from the attached link. (This was a repost of Harlan’s entry on the Windows IR Blog. See updated link in the “Research Links”)

1. Use the Enscript from Lance Mueller to make a ‘dd’ image of your
2. Use the VHDTool to create a Virtual Drive from your dd image.
3. Open Disk Management (Click Start enter diskmgmt.msc into the
search field )
4. Mount your VHD as a Virtual Disk selecting “Read Only”

5. This step needs more testing and unfortunately I do not have the
time to do it. If you try to use Shadow Explorer at this stage it will
be unable to see the Virtual Disk. There may be a command
line/registry hack which will enable this but I have not yet explored
this option. The solution I did find was to reboot the machine. Once
rebooted Shadow Explorer can quite happily access the Volume Shadow
Copies and allows you to export any relevant files. There is no search
option unfortunately.

Registry Keys

File Locations
System Restore

Research Links

Forensic Programs of Use
Shadow Explorer

5/27/11- Changed the link for the reference in this post with the link to the original Windows IR Blog post by Harlan Carvey.

Take Artifacts with you using Evernote

Posted by:

Everyone’s favorite forensic tool, Mark McKinnon, contacted us recently to let us know he has imported all of the Forensic Artifact posts into Evernote. The Evernote page can be accessed and linked to your Evernote account here:¬†

If you have an Evernote account, you can now sync all the Forensic Artifacts posts across your computer as well your mobile devices. Offline access is also a major benefit. Hopefully all future posts (and other community generated offerings) will be synced with the notebook to keep things current.

Thanks, Mark!