Stuff

Powershell
In preparing to do some testing in a Windows 7 VM, I decided to beef up PowerShell to ensure that artifacts are, in fact, created.  I wanted to make sure anything hinky that was done in PowerShell was recorded in some way.

The first step was to upgrade PowerShell to version 5.  I also found a couple of sites that recommended Registry settings to ensure the Module Logging and Script Block Logging were enabled, as well.

The idea behind this is that there have been a number of cases I've worked that have involved some sort of obfuscated PowerShell...Meterpreter, stuff loaded from the Registry, stuff that's come in via LNK files attached to emails (or embedded in email attachments), etc.  Heck, not just cases I've worked...look at social media on any given day and you're likely to see references to this sort of thing.  So, in an effort to help clients, one of the things I want to do is to go beyond just recommending "update your PowerShell" or "block PowerShell all together", and be able to show what the effect of updating PowerShell will likely be.

DDE
There's been a good bit of info floating around on Twitter this past week regarding the use of DDE in Office documents to launch malicious activity.  I first saw this mentioned via this NViso blog post, then I saw this NViso update (includes Yara rules), and anyone looking into this will usually find this SensePost blog article pretty quickly.  And don't think for a second that this is all there is...there's a great deal of discussion going on, and all you have to do is search for "dde" on Twitter to see most of it.

David Longenecker also posted an article on the DDE topic, as well.  Besides the technical component of his post, there's another aspect of David's write-up that may go unnoticed...look at the "Updated 11 October" section.  David could have quietly updated the information in the post, but instead went ahead and highlighted the fact that he'd made a mistake and then corrected it.

USB Devices
Matt Graeber recently tweeted about data he observed in the Microsoft-Windows-Partition/Diagnostic Windows Event Log, specifically events with ID 1006; he said, "...gives you a raw dump of the partition table, MBR, and VBR upon drive insertion."  Looking at records from that log, in the Details view of Event Viewer, there are data items such as Capacity, Manufacturer, Model, SerialNumber, etc.  And yes, there's also raw data from the partition table, MBR, and VBR, as well.

So, if you need to know something about devices connected to a Windows 10 system, try parsing the data from this *.evtx file.  What you'll end up with is not only the devices, but when, and how often.

Registry
Eric Zimmerman recently tweeted about the RecentApps key in the NTUSER.DAT hive; once I took a look at the key contents, I was pretty sure I was looking at something not too different from the "old" UserAssist data...pretty cool stuff.  I also found via Twitter that Jason Hale had blogged about the key, as well.

So, I wrote a recentapps.pl and a recentapps_tln.pl plugin, and uploaded them to the repository.  I only had one hive for testing, so YMMV.  I do like the TLN plugin...pushing that data into a timeline can be illuminating, I'm sure, for any case involving a Windows 10 system where the someone interacted with the Explorer shell.  In fact, creating a timeline using just the UserAssist and RecentApps information is pretty illuminating...using information from my own NTUSER.DAT hive file (extracted via FTK Imager), I see things like:

{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE (3)
[Program Execution] UserAssist - {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE (0)
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\NOTEPAD.EXE RecentItem: F:\ch5\notes.txt

...and...

{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WScript.exe RecentItem: C:\Users\harlan\Desktop\speak.vbs
{1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WScript.exe (7)
[Program Execution] UserAssist - {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\WScript.exe (0)

Each of the above two listings of three entries from a timeline all occurred in the same second, and provide a good bit of insight into the activities of the user.  For example, this augments the information provided by the RecentDocs key, by providing the date and time at which files were accessed, rather than just that of the most recently accessed file.  Add to this timeline entries from the DestList stream from JumpLists, as well as entries from AmCache.hve, etc., and you have a wealth of data regarding program execution and file access artifacts for a user, particularly where detailed process tracking (or some similar mechanism, such as Sysmon) is not enabled.

Eric also posted recently about changes to the contents of the AmCache.hve file...that file has, so far, been a great source of artifacts, so I'll have to go dig into Eric's post and update my own parser.  From reading Eric's findings, it appears that there's been some information added regarding devices and device drivers, which can be very valuable.  So, a good bit of the original data is still there (Eric points out that some of the MFT data is no longer in the hive file), and some new information has been added.