Journey Into Incident Response

Every year brings a new round of reports outlining the current trends. Information security threats, data breaches, and even cyber crime are covered in the reports. The one commonality across every report is they are lacking the digital forensic perspective. The reports address the question of what are the current threats potentially affecting your information and systems. However, the DFIR point of view asks the follow-up questions: how would you investigate a current threat that materialized on your systems and what would the potential artifacts look like? If a DF Threat Report existed then I think those two questions would be answered.

What The DF Threat Report Could Contain?

I’d like to see the report use case examples to illustrate a specific threat on a system. I find it easier to understand an investigative method and potential artifacts by following along an examination from start to finish. A simple way to demonstrate the threats would be to just replicate it on a test system. The use of test systems would enable the threat to be discussed in detail without revealing any specific case details. The current trend reports would just be guides highlighting what threats to focus on.

To see what I’m talking about I’ll walk through the process of how threats can be identifed for the DF Threat Report. The threats can then be simulated against test systems in order to answer the questions I'm bringing up. In the past two weeks I read the Sophos Security Threat Report Mid-Year 2011 and Securelist Exploit Kits Attack Vector – Mid-year Update reports. I’m using both reports since they are fresh in my mind but the areas I’m highlighting as lacking are common to most threat reports I’ve read (I’m not trying to single out these two organizations).

Example DF Threat Report Topics

The Sophos Security Threat Report Mid-year 2011 talked about the different ways malware is distributed. The threats covered included web threats, social networking, and email SPAM / spearphishing. The Securelist Exploit Kits Attack Vector Mid-year Update discussed the popular exploit kits in use and what vulnerabilities are targeted by the two new kits in the list (Blackhole and Incognito). There are threats in both reports that merit further discussion and would fit nicely in a DF Threat Report.

Sophos stated they “saw an average of 19,000 new malicious URLs every day” with more than 80% of the URLs belonging to legitimate companies whose websites were hacked. The report provided some statics on the URLs before moving on to the next threat. The DF Threat report could take two different angles in explaining the web threat; the server or client angle. If the phone rang at your company and the person on the other end said your website was serving up malware then how would you investigate that? What are the potential artifacts to indicate if malware is actually present? How would you determine the attack vector used to compromise the website? Now for the client angle, a customer comes up to you saying there is a rogue program holding their computer hostage. What approach would you use to identify the initial infection vector? What are the potential artifacts on the system to indicate the malware came from a compromised website as opposed to an email? These are valid follow-up questions that should be included in the web threat’s explanation.

The next threat in the Sophos report was Blackhat search engine optimization (SEO). SEO is a marketing technique to draw visitors to companies’ websites but the same technique can be used to lure people to malicious websites. “Attackers use SEO poisoning techniques to rank their sites highly in search engine results and to redirect users to malicious sites”. As expected the report doesn’t identify what the potential artifacts are on a system to indicate SEO poisoning. I could guess what the system would look like based on my write-up on the potential artifacts from Google image search poisoning. However, answering the question by examining a test system is a better option than making an assumption.

Another threat in the Sophos report was the ongoing attacks occurring in Facebook, Twitter, and Linkdin. “Scams on Facebook include cross-site scripting, clickjacking, survey scams and identity theft”. On Twitter attackers are using shortened URLs to redirect people to malicious websites. LinkedIn malicious invitation reminders contain links to redirect people to malicious websites. Again, the investigative method and artifacts on a system were missing. The same question applies to this threat as well. What are the potential artifacts on a system to indicate Blackhat SEO?

Rounding out the Sophos threats I’m discussing is SPAM /spearphishing. A few of the high profile breaches this year were covered and a few of them involved spearphishing attacks. Unfortunately, there was no mention explaining the artifacts tying malware to a specific email containing an exploit. Nor was there a mention of how your investigation method should differ if there is even a possibility spearphishing was involved.

The Securelist Exploit Kits Attack Vector Mid-year Update report identified the top exploit kits used in the first half of the year. One interesting aspect in the report was the comparison between the vulnerabilities targeted by the Blackhole and Incognito exploit kits. The comparison showed the kits pretty much target the same vulnerabilities. The DF Threat Report may not be able to cover all the vulnerabilities in the list but it could dissect one or two of them to identify the potential artifacts left on a system from exploitation.

Conclusion

The process I walked through to identify content for the DF Threat Report used reports related to security threats. However, a DF Threat report could cover various topics ranging from security to cybercrime. The report’s sole purpose would be to make people more aware about how to investigate a threat that materialized on your systems and what might the potential artifacts look like? In my short time researching and documenting attack vector artifacts I’ve found the information valuable when examining a system. I’m more aware about what certain attacks look like on a system and this helps me determine the attack vector used (and not used). I think the DF Threat Report could have a similar effect on the people who read it.

It would take an effort to get an annual/semi-annual DF Threat report released. People would be needed to organize its creation, research/test/document threats, edit the report, and to release the report. I wouldn’t only be an occasional author to research/test/document threats but I’d be a reader eager to see the DF Threat Report with each new year. Maybe this is just wishful thinking on my part that one day when reading a report outlining the year’s trends there will actually be useful DFIR information that could be used when investigating a system.

In this edition of Links I think there is a little bit of something for everyone regardless if your interest is forensics, malware, InfoSec, security auditing or even good a rant ….

Digital Forensic Search Updates

The Digital Forensic Search index has been slowly growing since it was put together four months ago. Last Sunday’s update brought the sites in the index to: 103 DFIR blogs, 38 DFIR websites, 13 DFIR web pages, and 2 DFIR groups. The initial focus of DFS was to locate information related to specific artifacts as opposed to locating tools to parse those artifacts. My reasoning was because I didn’t want to weed through a lot of irrelevant search hits. Most tools’ websites only provided a high level overview of an artifact the tool parses instead of in-depth information. It made sense to leave out tool specific sites to reduce the amount of noise but things change.

A question I ask myself at times is what tool can parse artifact XFZ. I’m not alone asking the question because I see others asking the same thing. To make things easier in locating tools I’m now adding tool specific sites to the Digital Forensic Search. So far 15 websites and 7 web pages are indexed. I ran a few tests and the search results seem to be a good mixture of hits for information and tools. My testing was limited so if anyone sees too much noise then just shoot me an email telling me who the culprit is.

Let me know of any links missing from DFS

Windows Shortcut File Parser Update

My post Triaging My Way mentions a need I had for a command line tool to parse Windows Shortcut files. In my quest for a tool I modified the lslnk.pl perl script to produce the output I wanted. One of the modifications I made to the script was to examine all of the files in a folder and to only parse files with the lnk file extension. I was running lslnk-directory-parse.pl (modified script) against some shortcut files when the script would abruptly stop. The parsed information from the last file only contained the file system timestamps. Examination of the file showed that it was empty and this was what caused lslnk-directory-parse.pl to die. I made a slight modification to lslnk-directory-parse.pl so the script checks each files’ header to confirm it is indeed a Windows shortcut file. I uploaded the new scripts (lslnk-directory-parse.pl and lslnk-directory-parse2.pl) to the Yahoo Win4n6 group and added a version number (v1.1) in the comments.

There are always different ways to accomplish something. When faced with trying to parse all of the Window shortcut files in a folder I opted to modify an existing script to meet my needs. The Linux Sleuthing blog took a different approach in the post Windows Link Files / Using While Loops. The author uses a while loop with an existing script to parse all of the shortcut files in a folder. Their approach is definitely simpler and quicker than what I tried to do. I learned a lot from the approach I took since I had to understand what modifications to make to an existing script in order to get the output I wanted.

How to Mount a Split Image

Speaking of the Linux Sleuthing blog. They provided another useful tip in the post Mounting Split Raw Images. As the name of the post implies it is about how to mount a split image in a Linux environment. I can’t remember the last time I dealt with a split image since I no longer break up images. However, when I used to create split images I remember asking myself how to mount it in Linux. To others the question may be simple but I didn’t have a clue besides concatenating to make a single image. The Mounting Split Raw Images post shows that sharing information – no matter how simple it may appear – will benefit someone at some point in time.

$UsnJrnl Goodness

Bugbear over at Security Braindump put together a great post Dear Diary: AntiMalwareLab.exe File_Created. I recommend anyone who will be encountering a Windows Vista or 7 system to read the post even if malware is not typically encountered during examinations. The $UsnJrnl record is an NTFS file system artifact which is turned on by default in Vista and 7. Bugbear discusses what the $UsnJrnl record is and how to manually examine it before discussing tools to automate the examination.

What I really like about the post is the way he presented the information. He explains an artifact, how to parse the artifact, a tool to automate the parsing and then shares an experience of how the artifact factored into one of his cases. I think the last part is important since sharing his experience provides context to why the artifact is important. His experience involved files created/deleted on the system as a result of a malware infection. Providing context makes it easier to see the impact of $UsnJrnl on other types of investigations. For example, a reoccurring activity I need to determine on cases is what files were deleted from a system around a certain time. Data in the $UsnJrnl record may not only show when the files of interest were deleted but could highlight what other files were deleted around the same time.

Memory Forensic Image for Training

While I’m on the topic of malware I wanted to pass along a gem I found in my RSS feeds and seen others mention. The MNIN Security Blog published the Stuxnet's Footprint in Memory with Volatility 2.0 back in June but I didn’t read it until recently. The post demonstrates Volatility 2.0’s usage by examining a memory image of a system infected with Stuxnet. A cool thing about the write-up is the author makes available the memory image they used. This means the write-up and the memory image can be used as a guide to better understand how to use Volatility. Just download Volatility, download the memory image, read the post, and follow along by running the same commands against the memory image. Not bad for a free way to improve your Volatility skills.

Easier Way to Generate Reports from Vulnerability Scans

Different methods are used to identify known vulnerabilities on systems. Running various vulnerability scanners, web application scanners, and port scanners are all options. One of the more tedious but important steps in the process is to correlate all of the tools’ outputs to identify: what vulnerabilities are present, their severity, and their exposure on the network. Obtaining this kind of information from the scans was a manual process since there wasn’t a way to automate it. James Edge over at Information Systems Auditing is trying to address this issue in something he calls the RF Project (Reporting Framework Project). RF Project is able to take scans from Nessus, Eeye Retina, Nmap, HP WebInpect, AppScan AppDetective, Kismet, and GFI Languard so custom reports can be created. Want to know the potential vulnerabilities detected by Nessus, Retina, and Nmap against server XYZ? Upload the scans to the reporting framework and create a custom report showing the answer instead of manually going through each report to identify the vulnerabilities. I tested an earlier version of the framework when it only supported Nessus and Retina a few years ago. It’s great to see he continued with the project and added support for more scans.

Jame’s site has some useful stuff besides the RF project. He has a few hacking tutorials and some technical assessment plans for external enumeration, Windows operating system enumeration, and Windows passwords.

Good InfoSec Rant

I like a good rant ever once in awhile. Assuming the Breach’s I do it for the Lulz explains the reason the author works in security. It’s not about the money, job security, or prestige; he works in security because it’s a calling. The post was directed at the InfoSec field but I think the same thing applies to Digital Forensics. Take the following quote:

“Technology, and especially information security has always been more than a job to me. More than even a career. It's a calling. Don't tell my boss, but I'd do this even if they didn't pay me. It's what I do. I can't help it.”

I can’t speak for others but digital forensics is the most changing field I’ve ever worked in. Technology (hardware and software) is constantly changing in how it stores data and the tools I use to extract information are also evolving. Digital forensics can’t be treated as a normal 8 to 4 job with any chance of being successful. Five days a week and eight hours each day is not enough time for me to keep my knowledge and skills current about the latest technology, tool update, threat, or analysis technique. It’s not a job; it’s my passion. My passion enables me to immerse myself in DFIR so I can learn constantly and apply my skills in different ways outside of work for my employer.

I wouldn’t last if digital forensics was only a day job. Seriously, how could I put myself through some of the things we do if there is no passion? We read whitepapers dissecting artifacts and spend countless hours researching and testing to improve our skills. Doing either of these things would be brutal to someone who lacks passion for the topic. For example, I couldn’t hack it being a dentist because I lack the passion for dentistry. I wouldn’t have the will power to read a whitepaper explaining some gum disease or spend hours studying different diagnosis. Dentistry would just be an 8 to 4 day job that pays the bills until I could find something else. DFIR on the other hand is another story as I spend my evening blogging about it after spending the day working on a case.

It’s hard to believe a year has gone by since I launched my blog. I didn’t know what to expect when I took an idea and put it into action. All I knew was I wanted to talk about investigating security incidents but at the time I didn’t have the IR skillset. I also wanted to provide useful content but I was short on personal time to research, test, and write. I went ahead anyway despite the reasons discouraging me from blogging.

The experience has been rewarding. I’m a better writer from explaining various topics in a way that others can learn from my successes and failures. I have a better understanding about DFIR from the feedback I received. The feedback also helps to validate what 'm thinking and doing. Different opportunities arose -such as talking with other forensicators- as a direct result of my willingness to share information.

The top six posts of the year covered a range of topics from detecting security incidents to examining an infected system to a book review. The most read posts of the year were:

     1.  Google the Security Incident Detector
     2.  Introducing the Digital Forensics Search
     3.  Reviewing Timelines with Excel
     4.  Review of Digital Forensics with Open Source Tools
     5.  Smile for the Camera
     6.  Anatomy of a Drive-by Part 2

I’m looking forward to another year and there is a range of ideas in the hopper. I’ll still touch on investigating security incidents as well as researching attack vector artifacts. However, my focus will gradually extend from the artifacts on a single system to the artifacts located on different network devices. Besides IR, I’m planning on talking about supporting financial investigations, Windows 7 (and Server 2008) artifacts, my methodology, different information security topics, and random DFIR thoughts inspired by things I come across along the way.

Thanks to everyone who keeps stopping by jIIr. There’s no need to be a stranger when there’s a comment feature to let me know what you think. ;) A special thank you to all of the other bloggers and authors who link to my blog and share their thoughts about my posts. I'm thankful for the additional traffic you send my way since it helps to let others know about the blog.

When I approach an analysis I perform the same initial steps to shed light on the system under examination. The first step is to review the master boot record and the second step is to obtain general information about the operating system and its configuration. The impact of the information on a digital forensic analysis can be significant.

Quick note before anyone takes the time to read further. My post doesn’t offer any new information. The registry keys referenced are well documented and the automation of Regripper is not new. I find it helpful to see how other analysts use tools and I thought others may feel the same way. My post demonstrates how Regripper can be automated in a batch file to reveal general information about a system; thereby saving some time when completing the information gathering examination step.

RegRipper is an open source tool for extracting data stored in the registry. When reviewing Regripper’s output I reference a document I created (outlines various artifacts) which allows me to see the data from registry keys in a specific order. I never thought twice about reviewing the output like this since I was only getting the initial information about the operating system. A couple of weeks ago I was going through Regripper reports when it dawned on me that I should automate the process. Create one report showing the information from the registry keys in a specific order. I wrote a small batch script to automate the creation of the operating system information report. If you just want the script then use the link at the end of the post. Otherwise, you can keep reading to see my thought process of how I put the script together before checking out the file. The script organizes information into the following five categories: general operating system information, user information, software information, networking information, and storage locations.

Thought Process behind the Batch File

        General Operating System Information

The first category has a significant impact on how the examination is conducted since it contains information about the operating system such as version, timezone settings, and machine security identifier (SID). The operating system version will dictate where certain artifacts are located and what tools can be used while the timezone settings should be self explanatory. The machine security identifier comes into play when looking at the user accounts’ SIDs since it shows if the user account is from the local or remote system. The following is the category’s information of interest and the registry keys containing the data:

* Operating system version and product name (HKLM\Software\Microsoft\Windows NT\Currentversion\)

* Registration information for owner and organization entered during installation (HKLM\Software\Microsoft\Windows NT\Currentversion\)

* Machine Security Identifier (SID) (HKLM\Security\Policy\PolAcDms)

* Shutdown information (HKLM\System\Controlset###\Control\Windows)

* Timezone information (HKLM\System\Currentcontrolset\Control\Timezoneinformation)

* Auditing configuration (HKLM\Security\Policy\PolAdtEv)

* Determine if the NTFS last access time is set to not to update (HKLM\System\CurrentControlSet\Control\Filesystem\NtfsDisableLastAccessUpdate)

        User Account Information

The next category obtains information about the user accounts associated with the computer. The information includes the configured local user accounts and groups as well as the artifacts of other user accounts (such as Windows domain users) logging onto the system. The category can help focus the examination on the activity of specific user accounts. The following is the category’s information of interest and the registry keys containing the data:

* Configured local user accounts and groups (HKLM\SAM\Domains\Account\)

* User profiles on machine and registered with Windows (Profilelist registry key)

* Logon username of the specified user account (HKCU\ Software\Microsoft\Windows\CurrentVersion\Explorer)

* Previous user accounts to log onto the machine (HKLM\Software\Microsoft\Windows NT\Currentversion\Winlogon\Defaultusername and HKLM\Software\Microsoft\Windows NT\Currentversion\Winlogon\Altdevaultusername)

        Software Information

The software category obtains information about programs installed and executed on the system. Knowing the software on a system can help shed light on the potential data available. For example, if the examination is interested in locating financial files then the software category will reveal the financial programs on the system thereby identifying the relevant file types. The following is the information of interest in the category and the registry keys containing the data:

* Programs showed on the Add/Remove Programs control panel applet (HKLM\Software\Microsoft\Windows\Currentversion\Uninstall)

* File system paths to various programs (HKLM\Software\Microsoft\Windows\Currentversion\App paths)

* Information about installed products (HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData)

* Default web browser (one area to check is HKLM\Software\Classes\HTTP\shell\open\command)

* User specific software (HCU\Software)

* User activity via the Windows Explorer shell may show programs ran (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist)

* Executables associated with the user account (XP is HKCU\Software\Microsoft\Windows\ShellNoRoam\MUICache and Vista/7 is is HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache in userclass.dat)

        Networking Information

The next category obtains information about networking such as the computer’s name, network shares, and firewall settings. The majority of computers are connected to some sort of network and the information in this category helps explain the type of network the system came from. The following is the information of interest in the category and the registry keys containing the data:

* Computer name (HKLM\System\Currentcontrolset\Control\Computername)

* Domain and hostname (HKLM\System\Currentcontrolset\Services\Tcpip\Parameter)

* Configured network shares on the computer (HKLM\System\Currentcontrolset\Services\Lanmanserver\Shares)

* Configured persistent routes (HKLM\System\ControlSet###\Services\Tcpip\Parameters\PersistentRoutes)

* Firewall configuration (HKLM\System\Currentcontrolset###\Services\Sharedaccess\Parameters\Firewallpolicy)

* Networking information (HKLM\System\Currentcontrolset###\Network)

* Cache of computers seen by Windows Explorer (HKCU\Software\Microsoft\Windows\Currentversion\Explorer\Computerdescriptions)

        Storage Location Information

The last category obtains information about the potential storage locations for user data. The category can reveal additional devices or folders that may contain data of interest. For example, the majority of Window systems I’ve seen in a corporate environment belong to a Windows domain where the IT departments have users store information on servers instead of their own computer (for backup purposes). One method used is to redirect certain folders in the user account’s profile – such as the My Documents- to a folder on the server. The storage location information category will quickly highlight this type of configuration. The following is the information of interest in the category and the registry keys containing the data:

* Devices and volumes mounted to the computer (HKLM\System\MountedDevices)

* Location of the user account profile folders (HKCU\Software\Microsoft\Windows\Currentversion\Explorer\User shell folders)

* Map network drives available to a user (HKCU\Software\Microsoft\Windows\Currentversion\Explorer\Map network drive MRU)

* Volumes mounted by a user (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2)

Putting the Batch File Together

Putting the batch file together was fairly simple since I already outlined the order of the information I wanted presented and Regripper had plug-ins to extract the data from the registry. The batch file repeats the following three lines for each Regripper plugin to create one report about the operating system and how it’s configured.

echo: >> operating_system_information.txt
rip.exe -r "%regpath%\SECURITY" -p polacdms >> operating_system_information.txt
echo .........................................................................................................>> operating_system_information.txt

The two lines starting with echo are for formatting purposes. The echo: inserts a blank line in the operating_system_information.txt while the other echo command inserts a line of dots to separate each Regripper plug-in. Rip.exe is the commandline version of Regripper and there are two options. The –r specifies the registry hive and –p specifies the plug-in to run. The variable %regpath% gets populated with a prompt for the folder path containing the registry hives.

The batch file gets put in the Regripper folder and gets executed by double clicking the file. Three screenshots show the script against an image mounted with FTK imager.

Prompt for folder containing the registry hives

Asks to parse user's registry hive then prompts for its folder location

Regripper parsing the registry hives and creating the report

Portion of the report showing the Software and Networking Information categories

The information in the report doesn’t include everything that I’d want to know over the span of an examination but it does provide the initial information about the operating system and how it’s configured. Automating the process makes me a little bit more efficient when I’m completing the examination step.

I uploaded the batch file to the jIIr Google site and the file can be downloaded here (to execute the file change the file extension from txt to bat).

A forensicator lives on the 10th floor of a building. Every morning he rides down the elevator to the ground floor and leaves the building to go to his forensic lab. Every night he comes home after spending the day finding evil and gets on the elevator. If it was raining then he takes the elevator to the 10th floor. If the weather is good then he takes the elevator to the 7th floor and walks to the 10th floor using the stairs. Why does he do this?

The forensicator in the elevator is an analogy to a malware infected system. Trying to answer the above riddle cannot be done without looking at the man in his environment (the building). Picturing the forensicator in the building and everything that is in the elevator will shed light on to question of why he takes the stairs. This is similar to answering the question of how malware infected a system. The question can’t be answered without looking at the malware in its environment (the affected system) and examining the other activity on the system around the time the malware appeared. Take the antivirus write-ups as an example. The majority of the write-ups (I’ve read) analyze the malware outside of the environment where it was located. As a result, the write-ups provide vague information on the initial infection vector used such as the statement “distributed through spam campaigns and drive-by downloads, though given its versatility, other vectors may also be utilized”. The description doesn’t shed much light on how a specific system became infected since pretty much all of the bases are covered (SPAM, drive-bys, or some other method). If you have ever wondered what the artifacts are of malware being delivered through SPAM then the rest of this article will be of interest.

Someone was nice enough to send me a SPAM email last month (sarcasm doesn’t come off the some way as the spoken word). The SPAM was a mass mailing so I was probably just one recipient out of thousands but at least the email gave me something to analyze. The examination of this email will first explain the user’s actions followed by the DFIR practitioner’s examination.

Accessing Email

        User Perspective

The user fires up a web browser to check their email. Internet Explorer loads the home page before the user navigates to Yahoo email. A few emails are checked before the user comes across the message below.


The user overlooks the indications that the email is SPAM such as the misspellings, punctuation errors, and even a run-on sentence (see the picture below to see what was missed). They proceed to read the notification letter alerting them to some kind of issue with their tax return.

      
        DFIR Perspective

The forensicator was slowly making their way through a system timeline when there was activity involving Internet Explorer. There were modifications made to few Internet Explorer folders in the Administrator user account’s profile and the user account visited a Microsoft’s webpage.


After weeding through all of the web activity related to the Microsoft webpage he noticed the user went to Yahoo’s webpage and accessed their webmail.


The browser history and cache showed that the user spent some time using Yahoo email.

Opening the Email Attachment

        User Perspective

Worried there might be an issue with their tax return the user decides to open the email attachment. The user felt more comfortable opening the attachment since Norton Antivirus indicated it was virus free.


The attachment doesn’t initially open a document but instead opens a new window showing a file with the name IRS document.exe. Even though file extensions weren’t hidden by Windows Explorer the user didn’t notice the exe extension since they were too distracted worrying about not receiving their tax refund.


        DFIR Perspective

The Internet activity indicated the user was still accessing their Yahoo email when an entry at 06/20/2011 22:10:00 showed the user downloading a zip file.


The file IRS%20document[1].zip was created in the folder \Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\M20M2OXX\ one second after the browser entry made a reference to a zip file in Yahoo email.

Aftermath of Accessing Email Message

        User perspective

The user double clicks the file named “IRS document.exe” thinking the file contains the list of missing documents but nothing visually occurs. A document doesn’t open, no error messages popup, and the list of missing documents isn’t shown. The user closes the attachment’s Explorer window at 06/20/2011 10:22 and continues surfing the Internet. This is the point in the story where the user perspective ends. The story tried to illustrate how someone could be tricked into opening the attachment in the SPAM email.

        DFIR perspective

The forensicator continued to work his timeline when there was a flurry of activity involving executables. The first artifact was a prefetch file for a program - IRS document.exe - (MD5 hash 77065d6545b0226ccf66ce75d5254bfa and link to the VirusTotal report) that was the executable inside of the zip attachment. 10 seconds later the Windows svchost.exe executable ran before two additional malware were dropped on the system. The malware was PUSK3_~1.EXE (MD5 hash 541c25d26e8b1eb2d1a35cd52854650f and link to the VirusTotal report) and tmp75D5.tmp (MD5 hash 4bda47a91bea4ceccc6003a46aeb754d and link to the VirusTotal report). The executable activity is shown in the picture below.


The forensicator tied the execution of the IRS document.exe and pusk3.exe to the administrator account by finding the following information in the account’s MUICache registry key.

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\Temporary Directory 1 for IRS%20document[1].zip\IRS document.exe (IRS document)
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\pusk3.exe (ProcFeatures)

The last artifact pointing to a zip file occurred at 06/20/2011 10:22 and it was modifications being made to the HCU\Software\Microsoft\Windows\ShellNoRoam\BagMRU registry key. A summary of the information in the BagMRU registry key is provided below.

* Bag: 9
* Registry Key modification Time [UTC]: 06/21/11 02:12:22.734
* Folder Name: IRS%20document[1].zip
* Full Path: Desktop\{CLSID_MyComputer}\C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\M20M2OXX\IRS%20document[1].zip\

Summary

The artifacts of malware being delivered through SPAM consisted of a user accessing email and opening a file around the same time. These artifacts hold true for malware being delivered via email even if the circumstances are different. At one point I examined an infected system which didn’t involve the IRS notification letter SPAM or web email. The activity on the system showed emails were assessed around the time a zip file was opened which happened just before the first piece of malware appeared on the system. All of the activity (and lack of other activity such as a drive-by download) lead me to conclude the malware was the result of a malicious email attachment. The specific artifacts in the examination varied slightly compared to what was discussed in this article but the general overall artifacts (email and file access prior to malware appearing) remained consistent.

Only examining malware from a system may not indicate email was the vehicle used deliver it. This is similar to antivirus write-ups about the analysis of malware which leave out information about how a specific computer became infected. The same line of thinking applies to the well known but slightly modified riddle at the beginning of the post. The riddle can’t be answered by solely analyzing the man outside of his building. Sure the analysis will reveal a lot of information about the man but it won’t explain why he is on the 7th floor of his building. The man needs to be analyzed in his building and the activity that occurred prior to him reaching the 7th floor should be reviewed. Trying to solve the riddle in this manner will reveal the answer of why he walks the stairs from the 7th to the 10th floor. The guy is too short to press the 10th floor elevator button and the highest he can reach - without an umbrella - is the 7th floor button. Like the man in the riddle, the activity on a system preceding the malware should be analyzed to determine if an email, drive-by, or some other means was used for the delivery.

Search engines are not only great tools for locating information across the Internet but they can alert organizations of potential security incidents. Others have already published methods on how to use search engines to locate information including web pages infected with SPAM links and common vulnerabilities. In addition to this information, search engines can help determine if a company's data has been stolen. Google queries and alerts can be leverage to assist organizations with noticing security issues such as data leakage, website vulnerabilities, and stolen information. This post will discuss an approach of using Google to search and monitor portions of the Internet for specific security issues.

Search Company’s Website for Security Issues

The term Google hacking refers to when search engine - such as Google - is used to locate weaknesses on the Internet. This is accomplished by building queries a specific way to locate sites containing software vulnerabilities, misconfigurations, or sensitive information. The same technique can be used by organizations to identify security issues on their own websites. What the specific issues are will be dependent on the organization but two possibilities are sensitive information and infected web pages.

     Sensitive Information

The business dictionary defines sensitive information as any information if compromised “could cause serious harm to the organization owning it”. Numerous types of data fit into this definition but three examples are: personally identifiable information (PII), credit card information, and network information.

PII can uniquely identify or locate a single person, and PII includes social security numbers, date of births, and addresses. A data breach from a few months ago illustrates the risk of PII being compromised. The personal information (names and social security numbers) of 300,000 people who applied for California workers' compensation benefits were mistakenly exposed online. As reported, the compromised PII was discovered last month after a data security company located the data through automated Google searching. The combination of breaches being reported in the media and the various data breach notification laws, it stands to reason that organizations should monitor their Internet facing sites for exposed PII. The Google queries below may locate information for social security numbers, birthdays, or contact information for specific websites.

ssn | “social security number” site:domain-name-here
dob | “date of birth” site:domain-name-here
“phone * * *” | “address *” | “e-mail” site:domain-name-here

The above queries contain a few symbols needing explnations. The pipe symbol ( | ) means “or” and the query will return hits if either term is present. The quotes ( “” ) mean the string of words has to match exactly while the asterisk symbol ( * ) is a wildcard and can represent any unknown terms. Site: makes Google only search the websites containing the specified domain (the query would contain the organization’s domain instead of “domain-name-here”). For additional information on syntax for Google queries check out Basic Search Help and More Search Help.

The company Blippy exposed data containing credit card numbers to the Internet. A few months later a company discovered the credit card numbers of four Blippy's users were in Google's index. In addition to PII, organizations could monitor their Internet facing websites for data related to credit card information. The Google queries below may locate information related to credit cards and amongst the information could be card numbers.

expiration | expdate | expire site:domain-name-here
CVV2 site:domain-name-here

Sosata.com (a Groupon subsidiary) accidently published a database containing email addresses and plain-text passwords of 300,000 users which was then indexed by Google. The accident was discovered after a security consultant located the exposed information on Google. Network information such as passwords, usernames, login pages, and errors can assist outside parties in attacking an organization. Companies can monitor their websites for leaked network information that may pose a risk to their network security. The Google queries below may locate: login pages, usernames, passwords, and errors.

login | logon site:domain-name-here
username | userid | employee.ID | “your username is” site:domain-name-here
password | passcode | “your password is” site:domain-name-here
intitle:error site:domain-name-here

     Infected Web Pages

The University of Calgary’s website was compromised and the attackers used the website to help sell pharmacy products. The Sucuri Research blog performed a Google search against the university’s website and was able to identify more than two thousand infected web pages. The compromise illustrates the point made by Unmask Parasites which was “to make their doorway pages rank better in search engines, spammers search for compromised web sites and use various security holes to insert hundreds of hidden spam links into trusted web pages”. Companies should add infected web pages to the list of what to monitor on their websites.

Google queries can identify infected web pages. The Unmask Parasites blog has a list of queries which can be used as a starting point for searching for SPAM links. In addition to the Unmask Parasites list, additional terms can be identified by using the blog’s Find Infected Pages with Google to locate infected web pages on the Internet. The portion of the infected web page displayed by Google can reveal other terms to use in a SPAM link query. The picture below shows an infected web page with the search terms used highlighted in bold.

Search Specific Websites for Stolen Information

The previous Google queries can help organizations identify sensitive information and infected web pages on their own websites. However, the queries won’t alert an organization to a compromise resulting in company information being stolen. A Naked Security article reported how the Atlanta Infragard chapter was compromised and the attackers “published 180 usernames, hashed passwords, plain text passwords, real names and email addresses”. How can a company feel confident that none of their employees’ information was compromised? Applying the same question to the publicize data breaches over the past year makes it even more difficult for a company to know if they are at risk. Google searches can help by querying the websites where stolen information is published.

One website with stolen information is Pastebin.com. Lenny Zeltser had a great article - The Use of Pastebin for Sharing Stolen Data – explaining what pastebin is and why hackers are using the site to share stolen information such as network configuration details and authentication records. Briefly reviewing Pastebin’s Trending Pages web page shows there is a range of information available from compromised credentials to identified vulnerabilities in websites. Organizations can search Pastebin.com to determine if their network is at risk because of stolen information. The Google query to accomplish is

site:pastebin.com +domain-name-here

The plus symbol ( + ) attached to the domain name makes Google match the domain exactly as it is typed. Pastebin is one example of a website to search but other sites, such as forums, should be queried as well. A few other potential websites to search are mentioned in Lenny’s post Using Pastebin Sites for Pen Testing Reconnaissance.

Automate Searching with Google Alerts

The previous Google queries will identify sensitive information, infected web pages, and stolen information currently in Google’s index or cache. To continuously monitor the Internet for this type of information an organization would need to periodically perform the queries to see if new information was added to Google’s index. Google alerts send email updates of the latest Google results based on the specified query and the alerts can hep organizations with the continuous monitoring. All of the previous queries can be configured as alerts and it's a fairly simple process to setup it up as can be seen in the screenshot below.

There are five required fields in setting up an alert.

* Search term: is where the query is placed
* Type: specify everything, news, blogs, realtime, video, or discussions websites
* How often: indicates the frequency of the email updates and can be set to as it happens, once a day, or once a week
* Volume: will show only the best results or all results
* Your email: the email address where the latest relevant Google results are sent

Summary

Google queries show the information currently in Google’s index and cache while Google alerts send email notifications when Google is returning new information. The combination of queries and alerts can be leverage by organizations to identify security issues such as data leakage, website vulnerabilities, and stolen information. The majority of the data breaches referenced had two things in common. The first commonality was sensitive company information was exposed to the Internet. The second commonality was the companies were notified about the data leakage after a third party located the information through Google searches. The approach of using Google to search and monitor portions of the Internet won’t prevent security issues from occurring in the first place. However, the approach may reduce the amount of time that lapses before an organization knows about the security issue.

My hope is at least a few people / organizations find this post helpful. It wasn’t my plan to write about the leakage of sensitive information (actually I was working on my next post Examination of a Phishing Email) but I wanted to inform others about the risk of leaked information.


References

Some of the queries I mentioned were obtained from the book Google Hacking for Penetration Testers and the Google Hacking Database.

I became involved in the digital forensics (DF) field when I had to establish and manage a DF process to support financial investigations and fraud audits. When I got to the point of identifying tools I first looked to see what resources I had at my disposal. Lo and behold my security lab had a dongle to a commercial forensic product. In the beginning I exclusively used a few commercial products to perform forensics but over time I added additional tools to my arsenal to expand my capability. I’m bringing up my background since the intended audience for Digital Forensics with Open Source Tools (DFwOST) is new forensic practitioners and experienced DF practitioners new to open source tools. My review of DFwOST is coming from the perspective of an experienced DF practitioner who may rely on a few (or single) commercial tools during examinations.

Before diving into the world of open source tools DFwOST starts out by defining digital forensics and explaining the goals of any examination which is for an examiner to locate artifacts to indicate if a hypothesis is true or false. DFwOST then covers the three different analysis types used during an examination and the analysis types are: system, application, and file. DFwOST explains how to perform the different analysis by explaining the data, the potential artifacts of interest located in the data, and discussing the open source tools to use against the data. The system analysis covers partitioning and disk layouts of physical storage devices. In addition to this, DFwOST discusses the different file types and artifacts specific to the Windows Linux, and Mac operating systems. The application analysis explains the artifacts associated with different web browsers and mail applications. Rounding out the discussion, the file analysis covers the activities for examining the content of individual files and their metadata. The authors provided a listing of references at the end of each chapter that the reader can use to learn more about the topics DFwOST doesn't go into great detail on.

I think DFwOST will be beneficial to anyone who reads it whether if they are new to the field or an experienced practitioner. However, I think the book is a great resource to experienced DF practitioners who are not familiar with open source and free digital forensic tools. My reasoning is because DFwOST can help to expand capabilities in DF examinations, understand how commercial tools work, and identify additional tools.

Expand Capabilities in DF Examinations

Every tool has its strengths and weaknesses, and commercial tools are no different. There is not a single commercial product that has the ability examine every possible type of data or artifact encountered during exams. This issue is one of the reasons why DF practitioners have multiple tools at their disposal. How does DFwOST fit into the picture?

First DFwOST discusses tools and techniques that have a capability not present in the current crop of commercial tools. The additional capability provided by open source tools can be used to compliment the functionality of commercial tools. For example, chapter 9 discusses the timeline analysis technique and mentions a few tools to create timelines that include the metadata from the file system and various artifacts. In my experiences, timeline analysis is a powerful technique and it has helped me on a range of different examinations from financial investigations to human resource policy violation investigations to security incidents. The ability to generate timelines would be lost by solely relying on a single or few commercial products.

Understand How Commercial Tools Work

Some commercial tools automatically extract information from data and this functionality can help reduce the time needed to complete an examination. On the downside, automation provides a layer of abstraction that may result in examiners not completely understanding the data they are seeing or how the tool works. The tools (open source and free ones in Appendix A) highlighted in DFwOST can be a great educational benefit to examiners by helping better understand the data and how their commercial tools work; thus removing the layer of abstraction caused by automation. Open source tools can not only be ran against data to see how the output is different but the tools' various options can be tested and the code can be read to better understand how the tool functions. The educational benefit provided by open source tools will be helpful to any examination even if the tools are not actually used on a case.

Identify Additional Tools

DFwOST points out numerous tools to use during a digital forensic examination. Using additional tools can provide flexibility and additional resources for validation testing. At times there could be a need to only conduct a few activities and using a multipurpose commercial tool may be overkill for the task at hand. Additional time will be needed for a multipurpose tool since it takes time to load and configure the tool even if the task at hand is just to extract specific information from data. The tools in DFwOST provide this kind of flexibility.

In addition to flexibility, open source tools can be used in the validation testing of commercial tools. Does XYZ commercial software extract the information from a certain type of data properly? Does XYZ commercial tool work as advertised? Both questions can be quickly verified by reproducing the results with the open source tools discussed in DFwOST.

Five Star Review

Overall DFwOST will be a welcome addition to anyone’s DFIR library. The one topic I thought was missing from the book (or I overlooked) is mentioning the process or methods to validate digital forensic tools before they are used during an examination. I don't think the authors had to go into great detail on the subject but pointing the reader (especially people new to the field) to a few references could be helpful. Despite this, if I was posting my review on Amazon then DWwOST would get another five star rating.