Updates

Case Studies
Brett Shavers posted a fascinating article recently, in which discussed the value of case studies throughout his career, going back to his LEO days. I've thought for some time now that this is one of the great missed opportunities of the DFIR community, that more analysts don't share what they've seen or done.  At the same time, I've seen time and again the benefit that comes from doing something like this...we get a different perspective, or we learn a little bit more or new, *OR* we learn that we were incorrect about something, and find out what the real deal is...this can have a huge impact on our future work.  Throughout the time I've been involved in the community, I've heard "...but I don't want to be corrected..." more than once, and to be honest, I'm not at all sure why that is.  God knows that I don't know everything and if I've gotten something wrong, I'd love to know what it is so that I don't keep making the same mistake over and over again.

Taking Brett's blog post a bit further (whether he knew it or not), Phill Moore shared a post about documenting his work.

Cisco Talos Intelligence - Decoy Documents
The Cisco Talos Intel team recently blogged regarding the use of decoy documents during a real cyber conflict.  What I found fascinating about this write-up was the different approach that was taken with the documents; specifically, the payload is base64-encoded and spread across the document metadata.  When the document is opened, a macro reportedly extracts the segments from the metadata variables and concatenates them together, resulting in a base64-encoded PE file.  The folks at Talos were kind enough to provide hashes for three decoy documents, which were all available on VirusTotal (searching for some of the metadata items returned this Hybrid Analysis link).  As such, I took the opportunity to run them through my own tools (wmd.pl, oledmp.pl) to see what I could see.

The first interesting aspect of the documents is that even though the three documents were different in structure, some of the metadata (including time stamps) were identical.

For example, from wmd.pl, the three documents all contained the same information illustrated below:

Authress     : Rafael Moon
LastAuth     : Nick Daemoji
RevNum       : 7
AppName      : Microsoft Office Word
Created      : 03.10.2017, 01:36:00
Last Saved   : 04.10.2017, 14:20:00

From oledmp.pl, even though the first document had markedly different streams from the other two, the root entry and directory entries all had the same time stamp and CLSID:

Root Entry  Date: 04.10.2017, 14:20:11  CLSID: 00020906-0000-0000-C000-000000000046

So, given the combination of identical metadata and time stamps, it's possible that the values were modified or manipulated to their values.  I'd say that this is support by the fact that some of the metadata values were modified to include the

Remember, you can also use Didier Stevens' oledump.py to extract the compressed VBA macros.  For example, to view the complete VBA script from the second document, I just typed the following command:

oledump.py d:\cases\maldoc\apt28_2 -s 8 -v

Shoop*, there it is...the decompressed macro script.  Very nice.  Maybe Cory and I should do reprise DFwOST, and do a second edition, and include stuff like this, going beyond just tools for forensics, and looking at tools that allow you to parse documents, etc.

Something I've mentioned before are some values that I saw listed in the output of 'strings' run across the documents:

CMG="6B69C77E3682368232863286"
DPB="D6D47AEB8E3DE45AE45A1BA6E55A4B8B26955AAD8AB69D9BB0FF733C04402A5B44526BEF14E0D0"
GC="4143EDEEEEEEEEEE"

Again, I've seen these before in Office documents that contain macros, most times with different values.  The definition of these values can be found at the MS-OVA Project page, under the Stream example, and I haven't yet been able to determine how these fields are populated.

LNK Files
I've posted several times over the past couple of months regarding parsing metadata from LNK files that are part of an adversary's toolkit; those either sent to a target as an email attachment, or embedded in another document format, etc.  US-CERT posted an alert recently that I found to be very interesting along the same lines, particularly regarding the fact that the adversary modifying Windows shortcut files as a means of credential theft. The big take-away from this information (for me) is that the adversary incorporated something that rudimentary about how the operating system functions and used it as a means for collecting credentials.

Of course, the "elephant in the room" is, why are organizations still allowing out-bound SMB traffic?

USB Devices
There's been a good bit of activity online recently regarding USB devices and Windows 10 systems.  Eric Zimmerman blogged about some changes to the AmCache.hve file that include a significant amount of information about devices.  Matt Graeber tweeted that "Microsoft-Windows-Partition/Diagnostic EID 1006 gives you a raw dump of the partition table, MBR, and VBR upon drive insertion", and @Requiem_fr tweeted that USB device info can be found in the Microsoft-Windows-Kernel-PnP%4Configuration.evtx Windows Event Log.

A little over 12 years ago, Cory Altheide and I published a paper on tracking USB devices on Windows XP systems, and it's been pretty amazing to see not only how this sort of thing has grown over time, but also to see the number of artifacts that continue to be generated as new versions of Windows have been released.

*Please excuse my taking artistic liberties to work in a Deadpool reference...