IOC Editor

MANDIANT IOC Editor is a free editor for Indicators of Compromise (IOCs). IOCs are XML documents that help incident responders capture diverse information about threats including attributes of malicious files, characteristics of registry changes, artifacts in memory, and so on. IOCe provides an interface into managing data within these IOCs including:

• Manipulating the logical structures that define the IOC
• Applying meta-information to IOCs including detailed descriptions or arbitrary labels
• Converting IOCs into XPath filters
• Managing lists of "Terms" that are used within IOCs

轉自  https://blog.mandiant.com/archives/2050?utm_source=rss&utm_medium=rss&utm_campaign=redline-openioc-build-effective-indicators

Recovering and Analyzing Deleted Registry Files

下載

Registry Decoder Digital Forensics Software

Digital forensics deals with the analysis of artifacts on all types of digital devices. One of the most prevalent analysis techniques performed is that of the registry hives contained in Microsoft Windows operating systems. Registry Decoder was developed with the purpose of providing a single tool for the acquisition, analysis, and reporting of registry contents. To learn the history of this project, please see the history page.


Registry Decoder is a free and open source tool. The online acquisition component can be accessed at: http://code.google.com/p/regdecoderlive/ and the offline analysis component accessed at: http://code.google.com/p/registrydecoder/.

All functionality contained within the two components is exposed to a graphical user interface, and the tool aims to provide even novice investigators with powerful analysis capabilities. Another goal of Registry Decoder is to become the project in which all future registry-related research is performed in and developed for. If you are a researcher and interested in open problems within forensics registry research or are interested in contributing the project, please see our research page here.

轉自 http://www.digitalforensicssolutions.com/registrydecoder/

Windows 7 Registry Forensics

How is management going to handle this situation? A typical approach would be to confront the workers. However, they most likely would deny any wrongdoing and probably try to obfuscate any potential evidence. Probably the best approach would be to covertly triage the live computers and perform post-mortem examinations of their hard drives. Frequently a business or corporation’s IT department members will lack the necessary qualifications or experience to perform these types of forensic examinations. This is not uncommon since IT personnel normally are not trained as forensic examiners.

Usually management will have to contract with an external digital forensics consulting firm to provide the services. In today’s world, it has become essential that management have processes in place (i.e. a plan) such that when an intrusion occurs or employee misconduct is alleged, they will have a firm foundation to support and assist with any potential civil or criminal proceedings. Failure to do so can have a detrimental effect upon the business or corporation.

Background
A Windows computer system has several forensically important areas where probative information can be found: in the computer’s RAM (if the system is live), in the Registry, or on the computer’s hard drive. The examination and extraction of probative information from a live computer system involves the use of triage tools which themselves will make changes to those same forensically important areas! Although this violates the “golden rule” of digital forensics, in some circumstances there is no alternative. Presuming that examiners have previously verified the functionality of their triage tools, they should have a fairly good understanding, and be able to document, what changes are made to a live computer system when they use those tools.

Unless they are involved in incident response, examiners are not often confronted with having to image a live system. Normally they would forensically image computer hard drives post-mortem, in a controlled work environment. The image would then be examined for probative information. Most forensic tools incorporate automated built-in features such as recovering deleted folders, performing keyword searches, carving data from unallocated space, searching directories and files, and so forth. Automated features are a necessity as it would be extremely labor intensive for an examiner to manually search a hard drive. In today’s digital forensics environment, examiners must have specialized training, knowledge, skills, abilities, tools, and experience to ensure reliable and repeatable results when triaging either a live system or examining a computer hard drive post-mortem.

What Is the Windows Registry and What Does It Do?
Early Windows operating systems included a “WIN.INI” file (which controlled the desktop and all applications on the computer system) and a “SYSTEM.INI” file (which controlled the computer’s hardware). They also used the configuration files “config.sys” (which loaded device drivers) and “autoexec.bat” (which ran startup programs and set environment variables). When Windows 3.1 was introduced, it was initially targeted to the corporate work environment. One of the assumptions made was that very few Windows applications would be installed on each computer. This would then limit the number of stored system and application settings. Since program developers still needed to store application specific settings, they used individual “.ini” human readable text files which were linked to the “WIN.INI” file. These were generally organized in groups located in a shared location. However, there were a number of drawbacks to this practice: it did not allow for user-specific settings in a multi-use environment; there were no rules placed upon their storage by the operating system; their proliferation and storage anywhere on the hard drive made it difficult or virtually impossible to manage and optimize their performance; and their size limitations and slow access often hindered system operation.

The release of Windows 95 introduced a new concept, the “Registry.” Its purpose was to store all application settings in a standardized binary format in a centralized location and replace text-based configuration and “.ini” files. Because it provided one unified solution for accessing both system and application settings, the Registry was initially praised by developers, users, and administrators. Its advantages included: the binary format allowing for more efficient file parsing; Registry settings loading from user-specific paths; permitting multiple users to share the same computer; accessing a computer remotely, allowing for ease of backups and restorations. However, the introduction of the Registry created another whole set of unintended consequences: it now became more difficult to back up and recover individual applications; automated installers and uninstallers became more complex because configuration settings had to be created by the applications; a damaged or corrupted Registry might fail to load the device drivers necessary to boot the system. With the continuing requirements and demands of complex applications and network solutions, each iteration of the Windows Registry has grown larger and more complex.

The Microsoft Computer Dictionary, Fifth Edition, defines the Registry as: “A central hierarchical database used in Microsoft Windows 9x, Windows CE, Windows NT, and Windows 2000 used to store information that is necessary to configure the system for one or more users applications and hardware devices.” Windows XP, Windows Vista, and Windows 7 also contain a Registry. Although referred to as a “central hierarchical database,” the Registry is in fact a collection of files that are located in the “C:\Windows\System32\config” and “C:\Users\(Username)\” directories (Windows 7). The Registry contains information that Windows continually references such as the applications installed on the computer, the user profiles, the hardware on or attached to the system, property sheet folder settings, the ports being used, application icons, and so on. From a forensic perspective, the Registry is a gold mine that can often provide probative information to an investigator. For instance, some of the information that can be found in the Registry includes:

• All the wireless networks that the computer has connected to
• Recent search terms
• Lists of the most recently used files or applications
• Autorun locations that list applications to automatically run when the computer is booted
• Contents of the User(s) desktop
• All USB storage devices that have been attached to the computer
• Malware (if it has installed itself as a service)
• The directory structure and file names contained on external devices that have been attached to the computer (pre-Windows 7)

While the Windows Registry is forensically important, frequently it is not captured during the triage of a live system. Similarly, it is often overlooked during post-mortem examinations. Daily, examiners are faced with many challenges: a lack of training to perform triage on a live system; examining multiple hard drives containing terabytes of data; dealing with pressures from management to complete an arbitrary, often unrealistic, quota of examinations per month; constantly juggling and prioritizing overwhelming case loads; shortages of personnel; and until recently, limited tools for examining Registry files. When faced with these challenges, it is easy to understand why the Registry is not often forensically examined.


轉自 http://www.dfinews.com/article/windows-7-registry-forensics-part-1?page=0,1

Computer Forensic Artifacts: Windows 7 Shellbags

轉自 SANS

As Windows Registry artifacts go, the "Shellbag" keys tend to be some of the more complicated artifacts we have to decipher. But they are worth the effort, giving an excellent means to prove the existence of files and folders along with user knowledge. Shellbags can be used to answer the difficult questions of data enumeration in intrusion cases, identify the contents of long gone removable devices, and show the contents of previously mounted encrypted volumes. Information persists for deleted folders, providing an invaluable reference for items no longer part of the file system.

A Brief Overview

Windows uses the Shellbag keys to store user preferences for GUI folder display within Windows Explorer. Everything from visible columns to display mode (icons, details, list, etc.) to sort order are tracked. If you have ever made changes to a folder and returned to that folder to find your new preferences intact, then you have seen Shellbags in action. In the paper Using shellbag information to reconstruct user activities, the authors write that "Shellbag information is available only for folders that have been opened and closed in Windows Explorer at least once" [1]. In other words, the simple existence of a Shellbag sub-key for a given directory indicates that the specific user account once visited that folder. Thanks to the wonders of Windows Registry last write timestamps, we can also identify when that folder was first visited or last updated (and correlate with the embedded folder MAC times also stored by the key). In some cases, historical file listings are available. Given much of this information can only be found within Shellbag keys, it is little wonder why it has become a fan favorite.

The Shift from Windows XP

The architecture of Shellbag keys within Windows XP is well understood and has been broadly covered [1,2]. However this is not the case with the Windows 7 format. I have recently had good luck using Shellbags within computer intrusion cases to show evidence of file system enumeration by attackers using compromised accounts. These systems have largely been Windows XP or Server 2003 and when I first sat down to review a Windows 7 system I was severely disappointed. Following the trend of many of our favorite Registry keys being updated in Windows 7, the Shellbag keys underwent a major transformation. Gone are the familiar Shell, ShellNoRoam, and StreamMRU categories that respectively denoted network, local, and removable device folders. Data from all of these locations still appears to be collected, but all three artifact categories are now stored within the Shell subkey. The keys themselves are stored as a slightly different binary format making manual deciphering even more painful. I was beating my head against the wall trying to reverse engineer the new format when Rob Lee suggested I do something really smart: leverage an existing tool and work backwards. He introduced me to the Tzworks Shellbag Parser and I was hooked. Besides being the only true Windows 7 Shellbags parser I am aware of, it does a remarkable job of parsing Shellbag structures.

What you need to know

Along with updating the Registry keys, Windows 7 also gave us a completely new user-specific Registry hive named USRCLASS.dat. This hive supports the new User Access Control (UAC) and the mandatory access control integrity levels now baked into the operating system. In oversimplified terms, it is used to record configuration information from user processes that do not have access to write to the standard registry hives. In order to get all Shellbags information, we now need to parse both NTUSER.dat and USRCLASS.dat for each user account. These Registry hives are located in the %user profile% and %user profile%\AppData\Local\Microsoft\Windows folders respectively. The specific Shellbag keys are:

USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU

USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\Bags

NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU

NTUSER.DAT\Software\Microsoft\Windows\Shell\Bags

Microsoft documents additional Shellbag keys that may be present on Win7 systems, but after a review of several Win7, Vista, and 2008R2 systems I have been unable to find any evidence of them being used [4]. For reference purposes, the additional keys are (Wow6432Node keys are located on x64 systems):

NTUSER.DAT \Software\Microsoft\Windows\ShellNoRoam\BagMRU

NTUSER.DAT\Software\Microsoft\Windows\ShellNoRoam\Bags

USRCLASS.DAT\Wow6432Node\Local Settings\Software\Microsoft\Windows\Shell\Bags

USRCLASS.DAT\Wow6432Node\Local Settings\Software

Parsing Shellbag Keys Using TZworks Sbag.exe

Using the TZworks tool to parse Shellbags is trivial. It is a command-line tool with just a few parameters. If you are working on a live system, you can use the "listhives" parameter to have it identify the available user Registry hives.

Once you know the paths of the hives you wish to parse, execute Sbag.exe and redirect the results to a .csv file (results are "|" delimited).

Finally, import the files into your favorite spreadsheet and start your analysis.

What information should you expect to gather from the Shellbags keys? Each folder will have:

• Bag Number [Identifies the "Bags" subkey containing user preferences — aka Nodeslot]
• Registry key last write time [First access of folder or last preference change]
• Folder name
• Full path
• Embedded creation date / time [Stored at the time the BagMRU key was created]
• Embedded modify date / time [Stored at the time the BagMRU key was created]
• Embedded access date / time [Stored at the time the BagMRU key was created]

My initial testing of TZworks Sbag.exe has found it to be highly reliable. In comparison to my previous go-to tool, Windows Registry Analyzer (which only accurately parses XP Shellbags), it does a more complete job, particularly with regard to timestamps. It works with both XP and Windows 7 artifacts, can parse both live and exported Registry hives, and the output is extremely easy to work with. Versions for Windows, Linux, and Mac OS X are available. If you haven't incorporated Shellbag review into your examinations, now is the time! Also, keep in mind that XP and Windows 7 Shellbag analysis is now included in the SANS 508 Advanced Forensics class.

[1] Zhu, Gladyshev, James (2009). Using shellbag information to reconstruct user activities, Digital Investigation, 6, S69-S77

[2] Shellbags Registry Forensics, John McCash

[3] Tzworks Sbag.exe

[4] Microsoft Support Article: Shellbag Keys

Installing pescanner.py on Windows

I don't often work with Python scripts, but I recently had an instance where, due to advice from a trusted source, I needed to run pescanner.py, mentioned in the Malware Analyst's Cookbook. In short, what I wanted to do was take look at a couple of suspicious executable files, having already run several AV scanners to identify and locate those files. Based on what I learned in setting this up, I wanted to share the steps I used to get this script running on Windows XP SP3.

Pescanner.py is a powerful tool that takes a look into a Windows portable executable (PE) file, and reports on "suspicious" elements of the file, if found, based on heuristics identified within the "Pimp my PE" paper. Pescanner.py can also incorporate YARA functionality so that PEiD and ClamAV signatures can be used, as well. This can be extremely valuable to an analyst, as we're all aware how AV alone often times will not detect malware. I've seen cases where malware was detected by the installed AV, only to have the timeline clearly show that at some point further down the road, another file with the same name was dumped on the system, but NOT detected by the same AV.

Install Python: I opted for ActiveState's ActivePython, but you can also get the current distro for Windows from Python.org.

Install Pefile: Do NOT use the pypm utility that ships with ActivePython to install the pefile module; instead go directly to the source and get the latest version. Download the archive and copy the pefile.py and peutils.py files into the Lib directory for your Python installation.

Download pescanner.py: Go here (this is rev. 18, get the most current one available) and get the file; the easiest thing to do is click on "View raw file" and save it where you want it to go. I had some issues getting the script running on Windows 2003, and it came down to the indentations...if you program Python, you may know what I mean. I had selected and copied the code in my browser, and pasted it into a Notepad window; when I saved the code using "View raw file" from the Google Code site, things worked. On my XP system, I pasted the code into an UltraEdit window and saved it.

Installing python-magic: According to this source, you'll need a couple of files to get python-magic installed on your system. First, go get the GnuWin32 file utility, and download the latest archive. Copy magic1.dll to your system32 directory and put the magic file in the same directory as pescanner.py. You can get regex2.dll from the latest regex archive (copy the file to your system32 dir), and zlib1.dll from the latest zlib archive.

For this one, I contacted MHL (one of the Cookbook authors...) and he sent me the below instructions for installing python-magic on Windows:

Assuming you already have Python from python.org or the ActivePython version...
1) Install setuptools
2) Get python-magic
* python setup.py build
* python setup.py install
3) Get the GnuWin32's File utility
* Place magic1.dll from the Binaries package into your system32 dir
* Place "magic" from the Binaries package into your system32 dir (or anywhere else, just as long as you remember the path)
* Place zlib1.dll and regex2.dll from the Dependencies package into your system32 dir
4) Test your installation
C:\> python
>>> import magic
>>> test = magic.Magic(magic_file='C:\path\to\your\magic')
>>> print test.from_buffer("test") ASCII text, with no line terminators

For more information, go here and here.

Again, many thanks to MHL for providing those instructions.

Another lesson here is to not stick with one tool or one set of tools, but instead be open to finding and using a tool or technique that works, and incorporating it into your toolkit. While Perl has the Parse::Win32Registry module and Python does not appear to have something comparable, Python does have the pefile module (on which pescanner.py was built) and Perl does not have (to the best of my knowledge) a comparable module. So rather than fitting the case to the tool, it's often a much better idea (albeit not easier) to find a tool or technique that will help you with your case.


轉自 http://windowsir.blogspot.com/2010/12/installing-pescannerpy-on-windows.html

Regripper - New Plugins from Harlan

Written by bshavers on 09 March 2011

Harlan submitted 4 new plugins, now included in the most current download (RegRipper030911.zip) on the download page.  The plugins in brief are;

notify.pl – updated output format to sort entries based on LastWrite time

renocide.pl -Plugin to assist in the detection of malware per MMPC

init_dlls.pl – Plugin to assist in the detection of malware per Mark Russinovich’s blog post

samparse.pl - Parse the SAM hive file for user/group membership info

Within the zipped RegRipper folder, these new plugins are located under RegRipper030911 > Additional Plugins  > Harlan Carvey

There are few resources of forensic software, used by pretty much every examiner on the planet, that you can get for free, which is also constantly updated by users of RegRipper and Harlan.   Although I said mentioned that RegRipper is “free“, it really isn’t totally free, as if users of RegRipper can contribute anything, no matter how little, it will benefit everyone that uses the program.   Whether by writing plugins (or suggesting a plugin to be written), giving feedback on using RegRipper, sending sample hives, or just sending a simple ‘thank you’ helps to keep RegRipper going.  As to how many examiners use RegRipper…I’ve not met a person that hasn’t used it and not have it benefit a case.


轉自Regripper

Google Chrome Browser Profile

 

Windows Vista/Windows 7

Author Name
Joe Garcia

Artifact Name
Google Chrome Browser Profile Folder (Windows Vista/Windows 7)

Artifact/Program Version
Windows Vista/Windows 7

Description
As part of a lot of Digital Forensics investigations, obtaining information of the user’s browsing habits is an important step. We see lots of articles on IE & Firefox, but what about Google’s Chrome Browser? Like Firefox before it, Chrome is steadily gaining in the browser market share. This post looks to point out where to find the Chrome user’s Profile folder. Most times, this will be saved as “Default”, but be on the look out for multiple profiles. Once you locate and extract the Chrome Profile folder (listed below) from your image, you can use tools like ChromeAnalysis or ChromeForensics to assist you in parsing out the information stored within it. You will get the following data, which is stored in SQLite files:
History (Web, bookmarks, downloads and search terms)
Cookies
Web Logins
Archived History (Web History and search terms)
Bookmarks (This is in a non-SQLite format)

File Locations
HardDrive\Users\USERNAME\AppData\Local\Google\Chrome\User Data\Default

Research Links
Get Google’s Chrome Browser HERE

Forensic Programs of Use
ChromeAnalysis from forensic-software.co.uk: http://forensic-software.co.uk/chromeanalysis.aspx
ChromeForensics by Woanware: http://www.woanware.co.uk/?page_id=70

Windows 2000, Windows XP, Windows Server 2003

Author Name
Joe Garcia

Artifact Name
Google Chrome Browser Profile Folder

Artifact/Program Version
Windows 2000/Win XP/Windows Server 2003

Description
As part of a lot of Digital Forensics investigations, obtaining information of the user’s browsing habits is an important step.  We see lots of articles on IE & Firefox, but what about Google’s Chrome Browser?  Like Firefox before it, Chrome is steadily gaining in the browser market share.  This post looks to point out where to find the Chrome user’s Profile folder.  Most times, this will be saved as “Default”, but be on the look out for multiple profiles.  Once you locate and extract the Chrome Profile folder (listed below) from your image, you can use tools like ChromeAnalysis or ChromeForensics to assist you in parsing out the information stored within it.  You will get the following data, which is stored in SQLite files:
History (Web, bookmarks, downloads and search terms)
Cookies
Web Logins
Archived History (Web History and search terms)
Bookmarks (This is in a non-SQLite format)
File Locations
HardDrive\Documents and Settings\USERNAME\Local Settings\Application Data\Google\Chrome\User Data\Default
Research Links
Get Google’s Chrome Browser HERE
Forensic Programs of Use
ChromeAnalysis from forensic-software.co.uk: http://forensic-software.co.uk/chromeanalysis.aspx
ChromeForensics by Woanware: http://www.woanware.co.uk/?page_id=70



轉自Artifacts

RecentDocs

Author Name
Joe Garcia


Artifact Name
RecentDocs


Operating System
Windows XP, Vista, Win7


Description
When starting a forensic examination, a great first artifact to check out is RecentDocs (or Recently Used Documents).   By default, Windows will display 15 items in the “My Recent Documents” menu option.  This will include .doc, .jpg, .pdf, etc files.  This is a great way to get a quick look at what files the subject of your investigation has opened recently. For example, for Law Enforcement officers, this is a great place to look if you have to investigate a suspicious death.   Your victim may have actually created a suicide note on their computer and this artifact can help you find it.  For Corporate investigators, your subject may have been snooping around for the recipe of your company’s “Secret Sauce” (or whatever proprietary data you wish to insert here).  This artifact might show the document being opened on your subject’s computer.  This can be used to corroborate other evidence obtained during your investigation.

When opening this artifact in a program such as MiTeC’s Windows Registry Recovery or AccessData’s Registry Viewer, you will see the following:



RecentDocs artifact in Windows Registry Recovery by MiTeC
If you look at the Data in the “MRUListEx” Value, it will always start with the document that was opened most recently and work it’s way back. So in this case, document “08″ was opened most recently. Each entry in the “MRUListEx” is four bytes in length. So going back four bytes from “08″, we can see that “07″ was the next most recent document opened in this example.

You can also use everyone’s favorite registry parsing tool RegRipper to accomplish the same goal (and better might I add). RegRipper displays the RecentDocs in order from last opened to first opened. Again, this is defined by the default max number. Other documents opened earlier on will not be listed here.



RecentDocs displayed in RegRipper


Registry Keys
NTUSER.dat


File Locations
NTUSER\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs


Research Links
- Default Max Number of Recent Docs (Microsoft TechNet): http://technet.microsoft.com/en-us/library/cc975956.aspx


Forensic Programs of Use
AccessData’s Registry Viewer
Harlan Carvey’s RegRipper
MiTeC’s Windows Registry Recovery


轉自 http://forensicartifacts.com/2011/02/recentdocs/