— Chad Tilbury (@chadtilbury) June 11, 2013
The GUI control panel is a long-standing feature of Microsoft Windows, facilitating granular changes to a vast collection of system features. It can be disabled via Group Policy but is largely available to most user accounts (administrative permissions are required for some changes). From a forensic perspective, we can audit control panel usage to identify a wide range of user activity:
- Firewall changes made for unauthorized software (firewall.cpl)
- User account additions / modifications (nusrmgr.cpl)
- Turning off System Restore / Volume Shadow Copies (sysdm.cpl)
- System time changes (timedate.cpl)
- Interaction with third-party security software applets
While identifying individual system modifications is difficult, at a minimum we can show that a user accessed a specific control panel applet at a specific time. Context provided by other artifacts may provide further information. As an example, imagine you were reviewing control panel usage on a system and came across Figure 1.
Context is critical, and, while access to the Windows Security Center might not normally be particularly interesting, the fact that it was accessed immediately following the execution of a known (router) password cracking tool might make all the difference.
With the major expansion of forensic curriculum at the SANS Institute, I frequently get questions about what class(es) to take. If you are trying to decide between FOR408 (Windows Forensics) and FOR508 (Advanced Forensics and Incident Response), this is the best comparison I have seen online.
I found the following quote particularly insightful: “508 is not a more advanced version of the 408, it’s a completely different course with completely different objectives.”
— Chad Tilbury (@chadtilbury) May 23, 2013
Amanda Stewart at the FireEye blog dissected the PlugX malware remote access tool (RAT). Of particular interest is this beautiful graphic showing the attack progression. With decoys, DLL sideloading, encrypted payloads, process injection, and new payload retrieval, this attack pretty much has it all!
Last year I covered the free Encrypted Disk Detector (EDD) tool and challenged the community to help crowdsource its development [link]. Thank you to all that took part in the experiment. Magnet Forensics announced today that Encrypted Disk Detector version 2 is available [get it here].
In addition to encouraging additional development of EDD, a side benefit of the project was to get an idea of the most popular disk encryption products being deployed. Figure 1 provides the survey results, with Checkpoint Full Disk Encryption, Symantec Endpoint Encryption, and Sophos (formerly Utimaco) Safeguard rounding out the top three. I think many of us could have guessed that big players like Symantec and Sophos would be near the top, but I was surprised to see products like BestCrypt and SecureDoc pull ahead of Credant Technologies (now owned by Dell).
Like many great inventions, the idea behind F-Response is so simple and elegant it is hard not to punish yourself for not thinking of it. Using the iSCSI protocol to provide read-only mounting of remote devices opens up a wealth of options for those of us working in geographically dispersed environments. I have used it for everything from remote imaging to fast forensic triage to live memory analysis. F-Response is vendor-neutral and tool independent, essentially opening up a network pipe to remote devices and allowing the freedom of using nearly any tool in your kit. The product is so good, I really wouldn’t blame them for just sitting back and counting their money. Luckily, counting money gets boring fast, so instead the folks at F-Response have kept innovating and adding value. Their latest additions are new “Connector” tools: Database, Cloud, and Email.
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.
Harlan Carvey discusses the ramifications of Windows Registry anti-forensics on his blog: http://windowsir.blogspot.com/2012/08/setregtime.html.
You can find SetRegTime here: http://code.google.com/p/mft2csv/wiki/SetRegTime