One of the great pleasures of performing Windows forensics is there is no shortage of application execution artifacts. Application execution tells us what has run on a system and is often the pivot point that reveals important activity on the system. Why was FTP run on this workstation? Is it normal to see execution of Winsvchost.exe? Why was a privacy cleaning tool used for the first time during the system owner’s last week of work? While undoubtedly useful, our adversaries are more forensic-aware than ever and often take steps to eliminate application execution artifacts. At CrowdStrike we routinely encounter nation-state groups that attempt to delete Prefetch. Even the popular CCleaner anti-forensics tool defaults to clearing Prefetch and UserAssist data. Hence having additional sources of data can often mean the difference between an easy examination and a long, painful one.
Archives For Incident Response
The third release of the free CrowdResponse incident response collection tool is now available! This time around we are including plugins facilitating collection of Windows registry data. Our inspiration for this release was one of those vulnerabilities that just won’t die, Windows Sticky Keys, and we’ll show how to identify this attack while demonstrating the new additions.
RegDump recursively extracts Windows registry key and value data.
-d Nested output format
-s Recursive dump
<reg key> Registry key to start dump from
Valid registry hive names are: HKLM, HKCU, HKCR, HKU, and HKAU (pseudo key representing all users)
RegFile searches for registry string values (REG_SZ and REG_EXPAND_SZ) and identifies file path data. If the file exists on disk, file information, hash, and digital signature details are recorded. Continue Reading…
My recent webcast with Jaron Bradley was recorded and a link is available below. If you have been looking for an excuse to get more familiar with Windows PowerShell, have a look.
What Malware? Hunting Command Line Activity
There is a reason hackers use the command line, and it isn’t to impress you with their prowess. Throughout the history of Windows, the command line has left far fewer forensic artifacts than equivalent operations via the GUI. To make matters worse, the transition to Windows 7 and 8 has spread PowerShell throughout the enterprise. While it makes our lives easier as defenders, it does the same for our adversaries. Every time you marvel at the capabilities of PowerShell, you should fear how your adversaries may use that power against you.
In this CrowdCast we have collected tips and tricks from our incident responders describing how they are countering the command line threat. Learn to identify when it is in play, extract commands from memory and network packets, and see what is new on the horizon from Microsoft to make tracking command line activity easier.
CrowdResponse is a free tool written by Robin Keir from CrowdStrike. Robin has a long history of developing excellent tools for the community including SuperScan, BinText, Fpipe, and CrowdInspect. The goal of CrowdResponse is to provide a lightweight solution for incident responders to perform signature detection and triage data collection. It supports all modern Windows platforms up to Server 2012 and is command-line based making it easy to deploy at scale. Version 1.0 focuses on signature detection, with a powerful YARA scanning engine. It ships with a very detailed user manual but since only a few actually read such things, I thought it would be interesting to show the tool in action.
Running YARA Scans
YARA, or Yet Another Regex Analyzer, has become one of the leading tools for describing and detecting malware. A YARA rule consists of a series of strings tied together by a Boolean condition. It facilitates searching with text, hex, Unicode, wildcards, case-insensitivity, and regular expressions. Combining these options allows construction of complicated tests to limit false positives. As an example, consider this YARA rule:
Web shells epitomize the hacking tenant of hiding in plain sight. In a previous post, we showed how a web shell could hide as a single file among thousands present on a web server and as a single line of code in an otherwise legitimate page on a site. The best web shells are not detected by anti-virus and can defeat vulnerability scanning applications using novel techniques like cookie and HTTP header authentication. Identifying the presence of a web shell can be difficult, but there are effective and repeatable ways to find them in your network. Today we will cover log review, concentrating on the following techniques:
- SQL injection identification
- Directory enumeration
- Statistical web log analysis
Tom from the c-APT-ure blog recently pointed me to the Malware Analysis Quant Research Project spearheaded by Securosis. The goal of the project is to develop a malware analysis model, complete with specific processes and metrics. The published white paper is 53 pages. Every organization has a malware problem and rapid identification and scoping is a big step towards successfully allocating precious security resources towards important events like attacks from determined adversaries as opposed to commodity worms and malware. The open nature of the model allows existing infrastructure within your organization to be readily integrated, shifting the focus towards identification and measurement of any process gaps. Those of you routinely hammered by ROI questions will applaud the focus on actionable metrics aimed at cost quantification.
Microsoft Trustworthy Computing recently released several installments in their Targeted Attacks Video Series. While the short videos are largely low-tech, the accompanying documents provide detailed mitigation strategies. Mike Pilkington wrote an excellent review of the 282 page Best Practices for Securing Active Directory document on the SANS Forensics blog. The Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques deck is also worth a read. Interestingly, Microsoft lists common mitigation techniques like “smart cards and multi-factor authentication” and “jump servers” as having only minimal effectiveness.
Packers are most commonly used for compression, code obfuscation, and malware anti-reversing. While not always malicious, packers are often a clue to look a little deeper into a particular binary. Ange Albertini did a marvelous job of representing the (known) universe of executable packers in this infographic.
The full PDF file can be found here.
Device acquisition may not be the sexiest phase of digital forensics, but it has the most number of pitfalls and can result in catastrophic loss. If a practitioner makes a mistake during acquisition, the investigation may simply be over, with nothing left to examine. Establishing an acquisition process is important, and a critical part of your process should be checking for the presence of full disk and volume-based encryption. Disk encryption is more prevalent than many believe –I am anecdotally seeing it in use on nearly thirty percent of the computers I encounter. If a system is running, the examiner often has a one-time shot to capture any mounted volumes in their decrypted state.
The inherent challenge is how to determine if an encrypted disk or volume exists. From the perspective of the operating system, data on a mounted volume is available in unencrypted form. A separate abstraction layer takes care of encrypting write operations and decrypting data for read operations. Thus when encountering a live system, investigators are often left with ad-hoc tests to try and make a determination. They can look for telltale installed software, or particular icons present on the system, but there are few reliable ways to get a confident answer whether encryption does or does not exist.
I recently had the opportunity to collaborate with the SANS Institute Securing the Human team as a guest editor for their OUCH! Security Awareness Newsletter. It was a rewarding experience working with such a competent and professional team. The theme of the September 2012 newsletter is “Hacked: Now What?”. While I am more used to writing technical articles, topics in OUCH! are written at a higher level and oriented towards the average computer user. It was fun to collaborate on topics relevant to this audience. The goal of the newsletter is to serve as a free resource that organizations of any size can use to increase the security awareness of their employees. Looking back through the archives, I think it consistently achieves this goal.