UserInfo (Windows)

Author Name
Corey Harrell

Artifact Name
UserInfo

Artifact/Program Version
Windows Registry

Description
Microsoft Office documents contain metadata that show when a file was
created, modified, and user names. The user names in Microsoft Office
documents’ metadata is pulled from the UserInfo registry key of the
user account’s registry hive performing the actions. The values
responsible in the UserInfo registry are the UserName and Company
values.

The population of the data in the UserName and Company registry values
varies. The values are populated in the user account that installed
Microsoft Office with the user name and company entered during
installation. For the user accounts that are using Microsoft Office
but didn’t install it, the values are populated a little different.
The first time the user launches an Office application a dialog box
appears asking for the user name and initials. The information entered
in the dialog box is what results in the UserName value in the user’s
UserInfo registry key. The location of the UserInfo registry key
varies depending on the version of Microsoft Office installed on the
system.

Registry Keys
Microsoft Office 2007: HCU\Software\Microsoft\Office\Common\UserInfo
Microsoft Office 2003:
HCU\Software\Microsoft\Office\11.0\Common\UserInfo

Research Links
http://support.microsoft.com/kb/821550
http://journeyintoir.blogspot.com/2011/06/why-is-it-what-it-is.html


Forensic Programs of Use
Registry viewer such as the free MiTeC Windows Registry Recovery

轉自 http://forensicartifacts.com/2011/06/userinfo-windows/

Microsoft Office documents metadata

Microsoft Office documents contain metadata that may be relevant to a digital forensic examination. The metadata may show when a file was created, modified, printed, or what user accounts were used to perform those actions. Others have already researched the metadata in Microsoft Office 2003 and 2007 documents including providing programs to parse the metadata. A few of the write-ups are: Kristinn Gudjonsson’s Office 2007 metadata post, and Lance Muller’s Office Metadata EnScript & Updated Office 2007 Metadata EnScript posts. I was interested in understanding how different actions taken against a Microsoft Office document affect its metadata.

To help show the relevance of Office documents’ metadata I included the metadata from one of my test Word 2007 documents. Usually I manual examine the information in metadata on an as needed basis but I thought for this post it would be cleaner to show the information in report format. The text below is the output from Kristinn’s read_open_xml_win.pl script ran against a test Word document. The File Metadata section shows when the file was created, modified, printed, and what user accounts were used to perform those actions. Did you notice the last print date/time (2011-05-27T19:09:00Z) occurred one minute before the file was even created (2011-05-27T19:10:00Z)? I’ll touch on this later in the post which is why I pointed it out.

Document name: E:\office metadata testing\word 2007\Xp-2007-1sp.docx
Date:
--------------------------------------------------------------------------
Application Metadata
--------------------------------------------------------------------------
Template = Normal.dotm
TotalTime = 2
Pages = 1
Words = 1
Characters = 9
Application = Microsoft Office Word
DocSecurity = 0
Lines = 1
Paragraphs = 1
ScaleCrop = false
Company = Test-lab
LinksUpToDate = false
CharactersWithSpaces = 9
SharedDoc = false
HyperlinksChanged = false
AppVersion = 12.0000
--------------------------------------------------------------------------
File Metadata
--------------------------------------------------------------------------
title =
subject =
creator = test-2007
keywords =
description =
lastModifiedBy = test-2007
revision = 2
lastPrinted = 2011-05-27T19:09:00Z
created = 2011-05-27T19:10:00Z
modified = 2011-05-27T19:10:00Z

Usernames in Microsoft Office Metadata

Before looking into how different actions against a Microsoft Office document affect its metadata I think it is useful to know more about the usernames reflected in the creator and modifiedby attributes. The usernames are not populated with the name of the user account that performed the action since there is a value in the Windows registry containing the name to use.

When Office 2003 and 2007 is installed there is prompt asking for a user name and company. Those fields are already prepopulated with the information entered when the operating system is installed which is located in the registry key HKLM\Software\Microsoft\Windows NT\CurrentVersion (thanks Greg Kelly for this info). The prompt gives the user an opportunity to either change the user name or company or to leave the fields with the information entered during OS installation.

There is a registry key containing what user name and company was used when Microsoft Office was installed. To locate the registry key the Office program’s GUID must first be determined and this Microsoft article explains how to locate the GUID. The GUID of Microsoft Office programs I tested were 9040110900063D11C8EF10054038389C for Microsoft Office Professional Edition 2003 and 00002109110000000000000000F01FEC for Microsoft Office Professional Plus 2007. The registry key containing the information about the Office installation is: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\{GUID}\InstallProperties. The regowner and regcompany values in the registry key contain the user name and company entered during the Office installation.

The usernames and company information reflected in Microsoft Office documents’ metadata are pulled from the UserInfo registry key of the user account’s NTUSER.DAT hive performing the actions. The names of the two values containing the data in the registry key are UserName and Company. The location of the registry key varies depending on the version of Microsoft Office but the paths below show where the key is located for Office 2007 and 2003.

Microsoft Office 2007: HCU\Software\Microsoft\Office\Common\UserInfo
Microsoft Office 2003: HCU\Software\Microsoft\Office\11.0\Common\UserInfo

Now the question I found myself asking is how are the UserName and Company values initially populated in the UserInfo key? I previously explained the user name and company during Office installation because the entered information is used to populate the UserInfo registry key of the user account that installed Microsoft Office. For the user accounts on the system that are using Microsoft Office but didn’t install it, the values are populated a little different. The first time the user launches an Office application a dialog box appears asking for the user name and initials. The dialog box is prepopulated with the name of the currently logged on user. The information entered in the dialog box is what results in the username value in the user's UserInfo key while the company value comes from the information entered when the Office was installed.

The metadata shown above now has a little more meaning. The username test-2007 is not the name of the user account that created and modified the document but is the name listed in the UserInfo registry key. The name in the UserInfo registry key can be changed at any point but any changes will alter the last write time on the registry key. This means the last write time of the user account’s UserInfo key should be taken into consideration when examining metadata. If the registry key last write time is before the dates/times in the metadata (create, modify, or print) then the metadata reflects what is currently in the user account’s NTUSER.DAT hive. On the other hand, if the registry key last write time is after the metadata timestamps then what is currently in the user account’s NTUSER.DAT hive may not be what was there when the action was taken against the Office document (did I just hear someone whisper check the restore points or volume shadow copies for registry files).

How Actions Change Microsoft Office Metadata

The testing I conducted consisted of creating one document then performing different actions against copies of the document to see how the metadata changed. I only ran the tests against documents created by the following programs: Word 2007, Word 2003, Excel 2007, and Excel 2003. If I test other Office Programs in the future then I’ll update the post to reflect it. The observed changes in the documents’ metadata were consistent across all of the different versions of Office but there were some minor differences between the different file types. The Excel metadata differed from Word in the following ways: there was no revision number, some timestamps contained seconds, and the Save As function didn’t change the documents’ creation date.

I’m providing charts of how the metadata was affected by the different actions taken against the documents. The chart has information in the parenthesis to show what the metadata values were for one set of documents (the timestamps don’t include the date since it was the same for all of the documents).

Here’s the Microsoft Office Word Metadata Changes chart and Microsoft Office Excel Metadata Changes chart. The PDF versions can be downloaded from the jIIr site.

The charts show how different actions against a Microsoft Office document affect its metadata. There are quite a few takeaways but I’m only going to highlight a few.

* The metadata create date/time reflects when the Office program was opened as opposed to the first time the document was saved
* Copying an Office document doesn’t changed the metadata
* The metadata print date/time only changes when the document is saved after it is printed
* The Save As function results in the Word metadata create and modification date/times being the same while the modification date/time only changes in Excel metadata

Now let’s go back to the metadata I posted above. Do you remember that the last print date (2011-05-27T19:09:00Z) occurred one minute before the file was even created (2011-05-27T19:10:00Z)? There was one action taken against a Microsoft Word document that produced this pattern in the metadata. The action was printing a document then using the Save As function to create a new document. The metadata shown above is from the newly created document.

轉自 http://windowsir.blogspot.com/2011/06/updates-links-etc.html

NetworkList (Vista/Windows 7)

Author Name
H. Carvey

Artifact Name
NetworkList

Artifact/Program Version
RegRipper w/ networklist.pl plugin v.20090812

Description
Vista and Windows 7 maintain a Registry key named
“NetworkList”:

HKLM\Microsoft\Windows NT\CurrentVersion\NetworkList
This key appears to contain profiles regarding managed and
unmanaged networks, including wireless networks that the system has
connected to, including SSID, the date the profile was created, the
date last connected, the MAC address of the WAP, etc. This MAC can be
looked up in the SkyHook database, and possibly converted to a Google
Map.

Registry Keys
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList (Updated 6/3- Thanks to Troy)

File Locations
Software Hive

Forensic Programs of Use
RegRipper w/ networklist.pl plugin


轉自 http://forensicartifacts.com/2011/06/networklist-vistawindows-7/

Virtual Machine Files Essential to Forensic Investigations

By: JD Durick

If you are responsible for collecting and analyzing digital evidence, you are already aware of how platform and desktop virtualization are changing the way organizations, corporations, and government agencies deliver, store, and manage digital content. 

Virtualization adds an enormous level of complexity to an already complex field. As forensic practitioners tasked with performing examinations on enterprise virtual environments, they are confronted with the challenge of understanding what VM-related files are of significant importance. Should they acquire the Virtual Machine Disk (VMDK) related files of the Virtual machine in question? What about the snapshot, memory, swap, configuration, metadata, and log files? Each one of these files are essential in running the virtual machine and could assist forensic examiners in understanding the Virtual machine’s function and potential compromise. Below is a step-by-step listing of a virtual machine’s life cycle detailing six major specific states:

Virtual Machine life cycle in VMware ESXi 4 update 1:

Creation:

When a virtual machine is created, several important files are generated in the location specified by the user. These files include:

(.vmxf) – A configuration file for teaming features. Teaming is a feature used primarily with VMware workstation to allow administrators to logically group virtual machines for streamlined administration.

(.vmx) – The primary virtual machine configuration file. The .vmx file contains the bulk of the virtual machines settings, configuration, hardware support, and emulation features.

(.vmsd) – Virtual machine snapshot descriptor file. This empty file is created when you configure and generate a new virtual machine, and maintains information about the virtual machine’s snapshots.

(.vmdk) – The virtual machine disk descriptor file contains disk geometry, layout, structure, and physical properties. The disk descriptor will describe an extent that represents the physical storage used by the disk. The term “file extent” refers to how many different fragments or “data runs” there are for a file. At most, a logical VMFS-3 volume can have 32 physical extents.

(vmname-flat.vmdk) – This file is considered a monolithic flat disk that has been fully allocated with the start and end markers allocated. This type of disk could potentially contain old data that resided on the data store and was not properly cleared prior to allocation of the disk. This type of disk is the default standard when setting up a virtual machine via the vSphere client on ESXi 4.0 update 1.

Figure 1: Pre-creation snapshot and corresponding files of the Virtual Machine.

Startup:
When the VM is started, several additional files are created including:

(.log) – VMware log files contain extensive diagnostic information, configuration and run-time messages of the virtual machine. Specifically, the vmware.log file holds detailed information about the virtual machine such as: network interfaces and corresponding IP addresses, hostname, ESXi kernel information, and detailed times in which snapshots were taken and restored.

(.nvram) – The virtual machines Basic Input Output System (BIOS) settings can be found in the non-volatile random access memory file.

(.vswp) – A virtual machine swap file. When the virtual machine requires more memory to be allocated, the swap file will be used instead of physical memory even if its RAM setting is not overcommitted. As soon as the VM is started, a swap file for the VM is created. The swap file is created with the following format: vmname-[8 character hexadecimal number].vswp. In our scenario, it was lifecycle_ubuntu-8bcd0f28.vswp and 256 MB in size.

Figure 2: Files created after installation of the Virtual Machine.

Suspend:

When a virtual machine is suspended, a suspended state file (.vmss) is created that represents the state of the machine at the time it was suspended, or paused; the .vswp file is then deleted. Again, the .vmss file contained the same eight character hexadecimal number as was applied to the .vswp file.

Figure 3: Files that were created after VM suspension occurred.

Resume:

When a virtual machine is resumed from a suspended state, the .vmss file remains and the .vswp is regenerated.

Figure 4: Files changed after a VM resume was executed.

Snapshot:

The previously empty .vmsd file is now populated with information about the new snapshot that was just created. A .vmsn file is generated, containing memory contents for the virtual machine, however, only if specified in the snapshot options menu of vSphere.

A snapshot descriptor file (.vmsd) and redo logs (.vmdk) are generated to represent changes made after generating the snapshot. The parent .vmdk disk descriptor and extents are untouched, meaning this operation will provide a forensically sound image file.

The vmname-######-delta.vmdk file stores changes made to a virtual disk while the virtual machine is running. According to VMware, there may be more than one such file.

Specifically, the .vmsn file contains “strings” of importance such as potential running process and hidden files that can be analyzed by the forensic examiner. Currently, tools exist to compare snapshots of the same virtual machine to track the changes of altered or suspect files. Additionally, Volatility has been known to be successful when analyzing and dissecting virtual machine memory files.

Figure 5: Changes to the files after a snapshot of the VM was created.

Shutdown:

When a virtual machine is shutdown cleanly, the .vswp and .vmss files are deleted. During an investigation, a .vswp file may contain important data. However, after a clean shutdown it is deleted from the virtual machine directory.

Figure 6: Files that now exist after a clean 

shutdown are executed on the VM.

It is critical for forensic examiners to fully understand what information each file provides when conducting a forensic examination on virtual machines in a virtual enterprise environment. The above lifecycle has shown us the purpose and function of those VM files used during each of the six states. After the virtual machines corresponding files have been retrieved, numerous tools on the market today make it possible to mount, dissect, and examine their contents to glean valuable forensic evidence.

轉自 http://crucialsecurityblog.harris.com/2011/05/23/virtual-machine-files-essential-to-forensic-investigations/

反封包側錄套件 - Sniffjoke 0.4.1

SniffJoke實現了一系列反嗅探技術，但開始作為一個流行的框架。SniffJoke有一個完整的支持社區。SniffJoke是一個linux應 用程序，可以透明的處理TCP連接，對數據包進行延遲、修改和注入偽造。經過處理後數據包幾乎不能被被動竊聽技術截獲（IDS或sniffer）。目前，Sniffjoke更新至0.4.1版

工具下載：http://www.delirandom.net/sniffjoke/sniffjoke-howto-usage/

出自：BugZone - http://www.pulog.org/tools/2096/Sniffjoke-0.4.1/ 

System Version (Mac)

Author Name
Douglas Brush

Artifact Name
SystemVersion.plist

Artifact/Program Version
OS X 10.x (Client)

Description
When you start your Macintosh investigation it is important to know
what version of the operating system is installed on the computer. The
version of OS X (10.4, 10.5, 10.6) can shape and direct the analysis
as each version has certain unique characteristics for other artifacts
as well as their locations on the disk.

Macintosh operating systems use plist files (.plist) as repositories
for system and program settings/information. Plist files can wither be
in a binary-encoded format (bplist file header) or as XML.

To get the operating system version the first plist files you will
want to examine is the “SystemVersion.plist” located in
“/System/Library/CoreServices/” folder. With this knowledge you
can be aware of other plists and system artifacts that are unique to
the OS under inspection.

File Locations
/System/Library/CoreServices/SystemVersion.plist

Research Links

Forensic Programs of Use
plist Edit Pro (Mac):
plist Editor Pro (Win): 

轉自 http://forensicartifacts.com/2011/06/system-version-mac/

Evernote note storage

Author Name
Joseph W Shaw II

Artifact Name
Evernote note storage

Program Version
Evernote 4.3.1.4479

Description
Evernote is a tool used to capture, store, and share ideas and
information in the form of multimedia notes mixing text, images, pdfs,
and other document types into searchable “notes.” These notes are
stored in an SQLite database format. Records are appended to the end
of the database. As records are deleted, they are overwritten by new
records. However, data records can be retained inside of the database
when the SQLIite database is viewed in Text or Hex view.

File Locations
On Windows 7: C:\Users\\AppData\Local\Evernote\Evernote\Database\.exb

Forensic Programs of Use
SQLite Database Browser
EnCase 6.18.1.3 64bit

Old Record Search Hit

轉自 http://forensicartifacts.com/2011/06/evernote-note-storage/

Salvaging Digital Video Fragments

Posted By Eoghan Casey
Digital video is becoming a more common form of digital evidence with the increasing prevalence of video in computers, mobile devices and cameras. Digital cameras can create high quality videos, most smart phones can create videos, and the iPad2 has two cameras that can create videos. The videos created by such digital devices can be stored on removable storage media and on the devices themselves. Frequent creation and deletion of videos on these kinds of devices can result in fragments of deleted video clips that most file carving tools cannot salvage. In addition, when dealing with Flash memory dumps acquired from mobile devices, data at the physical level is often fragmented. Specialized methods and tools are needed to salvage deleted video fragments as demonstrated in this article using the contents of Flash memory acquired from a Motorola V3 (RAZR) mobile device.

File Carving Limitations

Most file carving tools require a known file header in order to salvage deleted data. For instance, to recover a deleted 3gp file, most carving tools look for the file headers such as the following.

Hex view of 3gp header in the Motorola V3 Flash memory dump

If the file is fragmented or the header is missing, the file carving approach will not salvage the deleted video successfully. In this example, a file carving tool that searched the Motorola V3 memory dump for several 3gp header signatures found two files in as shown in the audit log:

05/24/2011, 11:26:35
QuickTime 3GP (3gp), header: ftypisom
QuickTime 3GP (3gp), header: ftyp3gp
QuickTime 3GP (3gp), header: ftypmmp4
Default file size: 1024 KB
Maximum file size: 100 times (individual file type definition defaults sizes respected)

E:\Physical GSM Motorola V3 RAZR\Flex Partition 1140000-1fe0000.bin
Scope: 000000 - E9FFFF
Extensive byte-level search

9D0E80 - AD0E7F: 00001.3gp
B888F0 - C888EF: 00002.3gp

05/24/2011, 11:26:35
2 file headers were found. 2 files were retrieved.

However, the salvaged files were invalid because the original files were fragmented. Furthermore, the names and directory paths of these files were not obtained using this method, demonstrating a further limitation of file carving.

Salvaging Video Fragments

When video files are fragmented, it is necessary to consider the video file format in more detail. Fortunately, many digital video formats have a structure that can be used to find and salvage individual frames. A frame is a discrete section of the video that can have a timecode or sequence number and other characteristics that can be useful for salvaging digital video clips.





The defraser tool can be used to identify frames for several video formats in a forensic duplicate of any piece of storage media, including a removable storage card, computer hard drive and Flash dump from a mobile device. The following screenshot shows defraser used to detect video related data in the Motorola V3 memory dump.





Defraser showing video related data in the Motorola V3 memory dump





Although the defraser tool does not automatically piece together the frames into a video that can be played, it does make the frames available for manual reconstruction. With some effort, defraser may be used to combine fragmented frames into a valid video file that can be played.





As with file carving methods that rely on header signatures, the carving methods employed by defraser do not provide the filenames and directory path of salvaged video data in the context of the original file system.

File System Reconstruction

Ultimately, the most effective approach to extracting digital video files from acquired digital evidence such as a Flash memory dump from mobile device is to reconstruct the logical arrangement of data. On mobile devices, this logical structure involves the flash abstraction layer and file system. Using mobile device forensic tools such as Cellebrite Physical and XRY, it is possible to reconstruct and review logical file structure of a Flash memory dump as shown below with a 3gp video stored in an MMS related file in the Motorola V3 memory dump. Note that different tools may interpret the logical structure differently and show more files and folders, clearly demonstrating the importance of validating the results of forensic examination tools.





XRY/XACT showing the logical file system in the Motorola V3 memory dump





Cellebrite Physical showing the logical file system in the Motorola V3 memory dump





Extracting the MMS file using such a mobile device forensic tool and extracting the video content as discussed in the “Delving into Mobile Device File Systems” blog post results in a 3gp file that can be played using VLC media player.





Playing salvaged digital video using VLC Player

Examination of Salvaged Video

After salvaging digital video files it is important to review the resulting data closely for potential anomalies. For instance, using MediaInfo to extract metadata from video files shows details related to its creation and format. The following screenshot shows metadata from a 3gp video extracted from the Motorola V3 memory dump, revealing that the embedded date-time stamp was set to an incorrect date.





Metadata within a 3gp video displayed using MediaInfo





In addition, reviewing individual frames within a salvaged video file can reveal anomalies such as portions of two unrelated videos being combined into one salvage file. The following screenshot shows frames extracted from a 3gp file using DCCI Video Validator revealing footage from two unrelated video files.





Frames extracted from digital video using DCCI Video Validator

Conclusions

When a video file is fragmented or the header of a video file is overwritten, carving methods that rely on header signatures and contiguous files will not salvage video files successfully and may even incorrectly combine unrelated video fragments into a single file or fail to detect the presence of video content altogether. However, using specialized tools such as defraser, a digital investigator may be able to salvage fragments of video files and piece them together into a valid video file. This process of reconstructing video fragments is time consuming and error prone, particularly when dealing with numerous video files on a single piece of storage media or mobile device. Therefore, whenever feasible, it is preferable to reconstruct the logical arrangement of data to extract the complete content of video files. Whichever method is most effective for salvaging digital video, it is important to examine the results closely to ensure the accuracy and completeness of the resulting videos. Such a review includes inspecting embedded metadata for anomalies and reviewing keyframes for possible fragments of unrelated video footage.








轉自 http://blog.cmdlabs.com/2011/05/30/salvaging-digital-video-fragments/

利用Format 指令執行簡單Wipe

As versões mais recentes do Windows trazem um interessante recurso de sanitização utilizando o comando FORMAT do Windows. Já dei a dica no post Dados a venda no ML, e vou reforçar agora:

Nestas versões mais novas (Vista >), o bom e velho format ganhou um interessante parâmetro, o /p:passes , que realmente "zera" os setores do volume que se deseja formatar, "passes" vezes:

format e: /p:4

Com este comando, o drive E:\ foi sobrescrito 4 vezes com "zeros", e o resultado é o seguinte:

Todos os setores do disco literalmente "zerados"

轉自 http://forensics.luizrabelo.com.br/2011/05/wipe-no-format-do-windows-sem.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+BrazilForensicsBlog+%28brazil+forensics+blog%29

Windows 搜尋索引 - Windows.EDB

A pouco tempo atrás, lí um interessante artigo que sugeria montar arquivos wiped a partir do index do Windows. É uma solução muito interessante, já que o serviço de indexação do Windows cataloga praticamente todos os arquivos e dados dos usuários.

O Windows Search Indexer, serviço do Windows que indexa os arquivos para otimizar a busca de informações no disco, cataloga estes dados em um arquivo chamado Windows.EDB. Este arquivo utiliza o padrão Esent database, o mesmo padrão utilizado nas últimas versões do Windows Live Messenger (e também no Exchange server). Maiores informações sobre este formato Esent aqui.

Tentei acessar o conteúdo dese arquivo Windows.EDB pelo EnCase e pelo FTK, mas sem sucessm em ambos. Encontrei na internet algumas ferramentas, mas a que mais me chamou a atenção foi o EseDbViewer, que possui módulos específicos para arquivos no formato Windows Search Indexer e Windows Live Messenger, e também um generico para acessar qualquer arquivo neste formato Esent:

Ferramenta muito simples e objetiva, consegui visualizar muita informação interessante. Claro que não será fácil remontar um documento do Word por exemplo, mas dependendo da situação, pode ser extremamente útil...


轉自 http://forensics.luizrabelo.com.br/2011/05/ressuscitando-os-mortos-recuperando.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+BrazilForensicsBlog+%28brazil+forensics+blog%29

Firefox Profile Path (Linux)

Author Name
f4ktu4l

Artifact Name
Firefox Profile Path

Operating System
Linux

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

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

Research Links
http://renaissancesecurity.blogspot.com/2011/04/firefox-4-browser-forensics-part-1.html
http://davidkoepi.wordpress.com/2010/11/27/firefoxforensics/ (added by Joe)

Forensic Programs of Use
FoxAnalysis: http://forensic-software.co.uk/firefox_forensics.aspx (added by Joe)


轉自 http://forensicartifacts.com/2011/05/firefox-profile-path-linux/

System Install Date (Linux)

Author Name
Hal Pomeranz

Artifact Name
Linux system install date

Operating System
Linux

Description
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
finished.

$ 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/ssh_host_dsa_key.pub
-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/ssh_host_key.pub
-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/ssh_host_rsa_key.pub

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
/etc/ssh/ssh_host_*key*

Forensic Programs of Use
ls, stat


轉自 http://forensicartifacts.com/2011/05/system-install-date-linux/

Default System Time Zone (Linux)

Author Name
Hal Pomeranz

Artifact Name
Linux default system time zone

Operating System
Linux

Description
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
/etc/localtime.
ZONE=”America/Los_Angeles”
UTC=true
ARC=false

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

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
685e6cae6f7d63e690bf35b955ff4afb

/usr/share/zoneinfo/posix/America/Los_Angeles
685e6cae6f7d63e690bf35b955ff4afb /usr/share/zoneinfo/posix/US/Pacific
685e6cae6f7d63e690bf35b955ff4afb

/usr/share/zoneinfo/America/Los_Angeles
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
/etc/localtime
/usr/share/zoneinfo

Forensic Programs of Use
zdump
find, md5sum, grep


轉自 http://forensicartifacts.com/2011/05/default-system-time-zone-linux/

iOS 4問世一年後 硬體加密終遭破解

俄羅斯數位鑑識工具廠商Elcomsoft表示已率先成功破解iPhone 4的資料安全防護，這意謂該公司已突破iOS 4的硬體加密技術。

何以iOS 4問世將近一年後才有辦法取得其中資料？Elcomsoft CEO Vladimr Katalov在部落格中指出，該公司發現破解iOS 4裝置image加密的方式，破解image極為有用，並可用鑑識工具，像Guidance EnCase、AccessData FTK，或其他支援硬碟image及HFS+檔案系統的工具來分析。

iOS 4版之前，要取得bit level Apple iPhone、iPod Touch及iPad裝置內檔案系統的快照以復原資料相當容易，和把DVD轉成ISO檔案類似。但到iOS 4時，蘋果加入硬體加密的技術，意謂著，即使拿到檔案系統，若不知加密金鑰也無能為力。

若想成功從裝置抓出資料，調查人員也必須能存取硬碟才能解密。「若碰不到裝置本身是不可能解密的，因為我們必須取得存在裝置內的密鑰，而且途中不能丟棄或儲存。」Katalov說。

然而從iOS 4取得的資訊很有限，除非鑑識調查人員（或駭客）知道裝置的密碼，因此預防的最好方法是以長而繁複的密碼取得「簡單密碼」以免透過字典攻擊法猜出。

轉自 http://news.networkmagazine.com.tw/security/2011/05/27/24635/

計算機文件時間屬性，你瞭解嗎？

轉自 計算機取證技術

關文件時間屬性

Sprite最近骨折在家養病，開始專心研究X-Ways Forensics 16.0。16.0的漢化已經幫助stefan做完，但x-ways 官網上還沒有公開發布。

過去寫的x-ways forensics  培訓教材有些老了，用的還是14.x的版本做的演示，一直沒有時間重寫，這次總算可以踏實專心地寫了。為了教 材，重新編制案例文件，但測試中發現對於文件時間一直沒有清楚地解釋過。其實文件時間是在司法實踐中非常重要的內容，為了更清楚地說明各種時間屬性，整理 來了一些材料供大家參考。

利用x-ways Forensics查看文件時間

從這些時間中能證明什麼？

 調查員、律師、法官們是否真正瞭解一個文件日期和時間屬性？從最早的DOS到現在的圖形化操作系統，計算機對文件時間的的記錄和解析已經非常清楚了。但是，一個文件所顯示的時間真是可以相信的嗎？ 

 真實且科學的說法是，文件的時間戳並不能完全相信。這個問題最早起源於計算機的時鐘的討論。計算機時鐘的最大的問題在於其依賴於電池供電，另外就是當前計算機時間是否已被校準。通常我們都知道，計算機的時間是可以被人為修改的。此外，不同的計算機系統也會採用不同的時間記錄方法，因此文件時間也會包含不同的 類型操作系統生成的時間。鑑此，無論訴訟方或者辯護方包括裁判方，各方都應該對計算機時間以及文件時間有一個全面的瞭解。

 當 前流行的操作系統、文件系統針對文件主要記錄三個時間屬性，即：修改時間、訪問時間和創建時間。但是，這些時間信息不是完全不可干預的，用戶的不同操作行 為可能會導致某些時間信息的更改。這就出現了一個最常遇到的問題：為什麼某些文件的修改時間會早於文件創建時間。通常我們的理解都是：一個文件應該首先被 創建，然後才可能被編輯、修改，文件創建時間應該早於文件修改時間。但實際上，經常會發生文件修改時間比創建時間早的情況。

 修 改時間的是文件被最後寫入數據的時間。簡單來說，這是一個文件被用戶打開、編輯並保存時的時間，且與文件內容是否被修改沒有關係。當然也有特例，就是軟件 開發商通常將所開發軟件的文件時間設定一致。這是因為可以比較借此輕易判明某個軟件的版本。最後修改時間通常表示為一個文件的最後保存時間。

 訪 問時間是用戶或計算機系統本身對文件進行的某種操作時間，任何會可能導致文件創建時間和修改時間變化的行為都會改變文件訪問時間。最常間的行為是：文件打 印、移動、複製、查看（打開並未保存，）。此外病毒檢測、文件備份、系統維護等操作都會改變文件訪問時間。由於太多的操作都可能改變文件訪問時間，因此訪 問時間可以幫助掌握計算機系統的近期歷史行為。

 創 建時間並非僅僅表示一個文件是在何時被創建的。實際上，創建時間主要表明某個文件是什麼時候出現並保存在某個存儲介質上的。故，創建時間代表用戶或計算機 系統創建某個文件記錄的時間。通過此原理，我們可以理解為什麼複製文件會改變文件創建時間：由於用戶所複製的文件並沒有存在於即將複製的位置，因此計算機 系統會在複製位置創建了一個新的文件記錄，並賦予其當前創建時間。這樣，大家可以理解為什麼所複製文件的修改時間可能會先於創建時間。當一個文件被覆制、 或是下載的時候，發生此行為的時間通常會比原文件本身時間屬性晚。

刪 除時間是一個最難判斷的問題。我們很難從文件時間屬性來判斷某個文件到底是什麼時候被刪除的，因為計算機並不直接記錄文件的刪除時間。回收站記錄是唯一可 以記錄某個文件是什麼時間被刪除的，但前提是當該文件仍然保存在回收站之中，沒有被用戶清空時，才會發現這個文件的刪除時間。最後訪問時間能夠證明某個文 件的最後一次被計算機系統接觸過的時間，可以表明某個時間至少在該時間之前還曾經存在過，但不能證明在該時間之後發生的事情。因此，大家最好不要糾纏於文 件刪除時間這個問題。

此 外，值得大家關注的還有保存在文件內部的時間信息，也稱元數據信息。Microsoft Word 和Excel，數碼相機、手機拍攝的圖片都包含有時間屬性。這些時間信息與操作系統記錄的文件時間很有可能完全不同。一般來說，文件內部記錄的創建時間更 加準確。此外，某些應用程序還有可能保存一些其他的時間信息，例如文件打印時間。但需要注意的是，文件內部記錄的時間信息僅表示這些文件的創建和最後保存 和寫入時間，並不能說明是這些文件是何時被移動、複製和查看的。

word文件中的創建和打印時間

數碼照片中的時間屬性

最 後我們應該注意的是時區、夏令時和時鐘問題。如果一個文件是在西8區創建的，卻是被東8區的計算機進行檢驗，那麼時間檢驗結果是完全不一樣的。夏令時也應 該是一個需要注意的情況調查員應該清楚地查明計算機時區和夏令時規則，這些信息可以從Windows註冊表中分析到。計算機時鐘總是可能發生偏差，取證過 程中應準確記錄當前狀態下的計算機時間。利用系統時鐘和當前時間的時差，可以輔助判定有關文件時間的一些問題。

除 此之外，調查官還應該密切關注所有計算機中出現文件的時間關聯，以及當前案件其他事件的時間關聯。例如，如果發現某些文件的創建、修改時間非常接近，僅僅 差距幾分幾秒，那麼無論時區或者時鐘是否有差異問題，律師們都會針對創建、修改、訪問時間出現各種爭論。此時，如果能有其他的外部事件時間加以輔助，例如 某個時段恰巧在度假或參加了什麼週末活動，那麼完全可以幫助證明或否定有關時間的猜疑。

因 此說，文件時間可以在法律環節中證明一些問題，但是法官們也不應把這些時間問題作為全部的評判依據。計算機的時間戳是不會為自己證明正確與否，人是解釋問 題的根本。應該說，計算機時間很重要，它既可以被作為訴方的證據，也可以被作為辯方的依據。如何才能夠有效地利用時間信息呢，斷案者必須要真正地瞭解計算 機和文件時間屬性。