Thursday, May 02, 2019

EvtxECmd

Eric Zimmerman recently released EvtxECmd, a nifty Windows Event Log file parser that bypasses the Windows API.  There are a lot of advantages to a tool such as this; specifically, by bypassing the API, it doesn't succumb to the 'hiccups' that may occur as a result of files that weren't closed properly, or for some other reason, isn't formatted in a manner the API agrees with.  This is something I've seen with LogParser, as it uses the Windows API, and will fail to parse a file if there's something 'amiss'.

Using data from the Lone Wolf Scenario, I extracted some (not all) of the Windows Event Log files from the image, and used the following command line to run EvtxECmd against this subset of data:

evtxecmd -d F:\lonewolf\data\evtx --csv F:\lonewolf\data\evtx --csvf output.csv

Not only was the output file generated, but a lot of data flew by in the command prompt while the command was processing.  I thought that this might be useful information, so I deleted the output file and re-ran the command:

evtxecmd -d F:\lonewolf\data\evtx --csv F:\lonewolf\data\evtx --csvf output.csv > F:\lonewolf\data\evtx\evtxecmd_trace.txt

Once the command prompt returned, I had the output file, as well as the 'trace' file that contained all of the information provided via the prompt.  A good deal of it was very useful, such as metrics based on the event IDs (albeit without the event sources, or some other unique identifier) and the count of said event IDs found in that log file.  This can be very useful information, and as such, I'd recommend collecting it as part of your investigative process, and keeping it alongside your case notes.

As to the output of the command, the output file contained 31,956 entries; by comparison, Logparser (run via wevtx.bat) threw an error about not being able to open a file (it didn't specify which one), and produced output with 24,770 entries. Clearly, incorporating EvtxECmd into your investigative process will provide a more complete view of the available data, from a total number of events perspective.

However, let's look at some differences in the actual output.  I've always been fascinated by the use of BITS for downloading (and uploading) files.  As there are a number of BITS Client events available, let's look at a simple event, such as event ID 3.

The output from wevtx.bat, using Logparser, looks like this (i.e., TLN format):

1522194038|EVTX|DESKTOP-PM6C56D||Microsoft-Windows-Bits-Client/3;C:\Users\jcloudy\AppData\Local\Temp\{33340A58-DC7C-4FBB-82A9-24EFA8F8C38D}-gsync64.msi,{50A0E739-31CE-4B89-8972-DE76CC505D31},DESKTOP-PM6C56D\jcloudy,C:\Program Files (x86)\Google\Update\GoogleUpdate.exe,9004

The output directly from EvtxECmd for a similar event record looks like this:

279,279,2018-03-30 21:09:16.6870673,3,4,Microsoft-Windows-Bits-Client,Microsoft-Windows-Bits-Client/Operational,3636,11240,DESKTOP-PM6C56D,S-1-5-18,,,,,,,,,,,F:\lonewolf\data\evtx\Microsoft-Windows-Bits-Client%4Operational.evtx

In the case of the EvtxECmd output, there seems to be some important information missing. Talking to Eric about this, he said that in order to get the additional details (i.e., strings, event description) in the CSV output, you need to have a map file for the event.

So, there you go.  Once the appropriate map files are in place and the event description available as part of the output, given the header of the output file, it will be relatively easy to write a script that will translate the output of the tool into something easily incorporated directly into a timeline, for direct inclusion into an analysis process.

For your analysis process, Eric includes map files (read Eric's info for more detail...)...when I ran the tool, there were 52 map files available.  Eric provides a description of how to create your own map files.

A note on using Eric's CLI tools: whenever I install a system, one of my first configuration steps is to modify the command prompt to a white background with black letters.  This makes things much easier for screen captures, particularly for books and presentations.  When running Eric's CLI tools for the first time, I'll get a lot of blank lines in the output, and highlighting or selecting the contents of the screen does not reveal the underlying text.  I reached to Eric and he said that I needed to get the nlog.config file from his site, and include it in the directory with each of the command line tools.  I simply created a folder for Eric's tools, and put one copy of the file alongside all of the other tools.

Resources
Link to EvtxECmd Maps

What's New...

Magnet Forensics Free Tools
The folks over at Magnet Forensics have several free tools available, which were discussed recently on the 13Cubed YouTube channel.

Analysis
Okay, so parsers abound (more on that later), but what then? Parsing is great, but that's just the first step toward analysis, and the true value of a tool, regardless of where it comes from, is how it integrates into your analysis process.  Parsing is not analysis.

On a bit of a side note on that topic, IWS was released last fall, and I'm still somewhat curious to see how it's received by the community. In the book, I exposed my analysis process, in a manner that anyone can follow along with; with the exception of the first image (which seems to be no longer accessible), anyone can download the images, and perform their own analysis.  This is a complete departure from my previous work; in all of my previous books, I'd followed a pretty standard formula...here's an artifact, here's how to parse it, here's what it can tell you...but like other works, I'd pretty much left it to the reader to figure out how to stitch everything together into a cohesive investigation.  IWS is my first real shot at doing that, going beyond just throwing up my findings into a blog post.  Yes, I've been told, "...it's good...", and "...I like it...", but like a brewer who's stepped outside their comfort zone and tried something radically different from their previous approach, I'm really curious to better understand what readers really think about the content of the book, how it impacts them, and

JumpList AppID
Not long ago, I saw a question about an Automatic JumpList application ID; the OP was asking which application the AppID referred to.  I did a quick Google search and found no reference to that specific AppID, but it did get me thinking...how can someone go about determining the AppID of a JumpList, when said AppID is not publicly listed?

I came up with two means for doing so, and in hindsight, they are not mutually exclusive; that is, one supports the other.

The first method would be to parse the JumpList and get a list of files that it points to; you can get this information from both the individual LNK streams within the JumpList file, as well as the DestList stream.  From there, you could then check the Registry for file associations; that is, which application is associated with the listed file's extensions.

The second method would be to create a timeline of system activity, and include the JumpList DestList stream as a data source.  With additional information, such as UserAssist and BAM entries, RecentDocs values, Prefetch metadata, etc., you should be able to 'see' applications that were launched prior to at least some of the files in the JumpList DestList stream being accessed.

Presentations
I've got a couple of upcoming presentations, the first one being at RVASec, coming up later this month. I've submitted to OSDFCon this year, as well, but that's in the fall.

A friend asked me to provide a presentation to her forensics class, which I did recently, via Zoom.  I resurrected a presentation on Registry analysis, which I thought was appropriate given the audience, and it seemed to pretty well-received.  If anything, I hope that seeds were planted.

Sunday, April 21, 2019

LNK Files In The Wild

The FireEye folks recently shared a fascinating article regarding a spear-phishing campaign that involved the use of 'weaponized' LNK files, two of which were of particular interest:

1. SPEC-10T-MK2-000-ISS-4.10-09-2018-STANDARD.pdf.lnk
MD5: ec0fb9d17ec77ad05f9a69879327e2f9

2. From the Related Samples section is another LNK file with a filename that includes the Ukranian word for "Conclusion"
MD5: fe198e90813c5ee1cfd95edce5241e25

It turns out there are some similarities in the metadata of the LNK files, but also some odd differences.

Similarities:
Basepath, shellitemIDlist: C:\Windows\System32\mshta.exe
Description: "Type: Text Document"
Iconfilename: ".\128_2_21.docx"
Commandline: Very similar, both point to same domain, although the command line in LNK 1 is base64 encoded, and in LNK 2, it isn't
PropertyStoreDataBlock: both contain the same SID, S-1-5-21-871675894-2481818095-1561791058-1002

Differences:
Volume SN: Volume serial numbers are different both systems
TrackerDataBlock: Both LNK files have different TrackerDataBlocks, including the machineID field.

In the past, similarities in LNK file metadata (machineID, volume serial number, MAC address) have been attributed to a single VM being shared.  So, the question becomes, how do different LNK files include the same user SID, but different volume serial numbers, NetBIOS machine names, and MAC addresses?

The MAC address artifact, I get.  I can also see how the iconfilename might be the same; personally, I'm a fan of re-using things that work.  The description field is entirely optional, and the fact that they're the same between LNK files is interesting.  In and of themselves, the different values in the TrackerDataBlock (machine ID, MAC address) are not unusual, but given that the SIDs are the same, that is odd.  Could it be the result of something like this?  If so, that's pretty darned specific.

Thoughts?

Monday, April 15, 2019

Registry Transaction Logs, pt II

My previous blog post on this topic was an initial look into what happens (i.e., changes, what 'new' data is available, etc.) when you merge Registry transaction logs into a hive.  This started out with me just looking at what tools were available for doing so, and then expanded a bit into, "oh, let's see what changes were made in the hive file...".

In this post, I wanted to provide a bit more information and clarification around what I did and what I found, so that others can more clearly see the process, and hopefully, the value of pursuing this sort of testing and research.

Clarification
My initial testing led to some very interesting findings, one of which was stated as the following:

The del.pl plugin produced some interesting results.  When I ran it against the original System hive, it pulled out a number of deleted keys and values; however, running it against the 'new' (i.e., merged) hive, I got nothing.  Not one deleted key, not one deleted value.

Now, the assumption here might be that there are no deleted keys and values after the transaction logs have been merged into the hive, and that would be incorrect.  The reason that the tool displayed no findings on the second run (and thanks to Maxim for providing insight into this...) is that the plugin only checks the beginning of a free cell for indications of a deleted key or value node; it doesn't traverse and check the entire cell.  This is why we have tool testing and verification, and what leads to those of us who write and use such tools to update them.

So, for the sake of clarity, merging the transaction logs into a hive file does not remove all unallocated space and deleted cells. That being said, there is significant value in running tools that check for deleted cells across both the original and the merged hives.

Tools
For testing, I opted for using the LoneWolf scenario image, as it is readily available.  Any hives and their corresponding transaction logs can be used, but going with a publicly available image allows for clarity and simplicity in discussions.  I opened the image in FTK Imager, and extracted System hive from the system32\config folder, along with the System.log1 and System.log2 transaction log files.

As to merging transaction logs into hives, I tweeted a question regarding tools used to merge hives and transaction logs. I got a response from Maxim, stating "yarp + registryFlush.py".  Once I got everything set up and running, this process ran as advertised.  I passed the necessary arguments to the script, and ended up with four files in the folder:

03/27/2018  05:45 PM        12,845,056 SYSTEM
09/29/2017  04:45 AM         3,163,136 SYSTEM.LOG1
09/29/2017  04:45 AM         3,211,264 SYSTEM.LOG2
04/08/2019  04:04 PM        12,845,056 system_2019-04-08@160420

At this point, I have the 'dirty' hive and transaction logs extracted from the image, as well as the 'merged' hive file.  Note that the file system reports the 'dirty' and 'merged' hives as being the same size.

Deleted Keys/Values
I mentioned checking for deleted keys and values at the beginning of this post; Maxim provided this advice regarding the use of the "yarp-print" tool as the more accurate approach to recovering deleted keys and values.

Specifically, if you're using yarp on Windows, start by opening a command prompt, navigating to the folder where the tools are located, and type:

set PYTHONIOENCODING=utf-8

Then, to parse deleted keys/values from the 'dirty' hive, you can use the following command:

yarp-print --deleted --no-recovery SYSTEM

In this case, you would used the --no-recovery switch as the tool will automatically attempt to discover the transaction log files.

In order to parse the deleted keys and values, incorporating the transaction logs into the process, you'd use the following command line, if you extracted the transaction logs into the same folder as the hive file:

yarp-print --deleted SYSTEM

Again, the yarp tools will attempt to discover the transaction logs for you, and incorporate them into the parsing.  This also means that you can use the yarp-print tool to extract deleted keys and values from the merged hive, using the following command:

yarp-print --deleted system_2019-04-08@160420

In this case, you don't have to use the --no-recovery switch, as the tool won't find transaction logs associated with the merged hive.

RegRipper
As I mentioned in my previous post, one of the interesting aspects of this testing was the differences in output from various RegRipper plugins when run against the 'dirty' and 'merged' hives.

The output of the mountdev.pl plugin, when run against the 'merged' hive, included an additional DosDevice entry:

\DosDevices\F:
  Drive Signature =  76 d4 59 81

The output of the bam.pl plugin, when run against the 'merged' hive, included two additional entries for the user with RID 1001:

Fri Apr  6 12:27:06 2018 - \Device\HarddiskVolume4\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE
Fri Apr  6 12:41:21 2018 - \Device\HarddiskVolume6\Programs\Imager_Lite_3.1.1\FTK Imager.exe

The same output also included an entry for the Local System account that was not in the 'dirty' hive:

S-1-5-18
  Fri Apr  6 12:40:38 2018 - \Device\HarddiskVolume4\Windows\System32\csrss.exe

Take-Aways
Just with this initial testing, using just this one hive, we can begin to see the value of making use of the hive transaction logs.  The System hive used in this case was not from a high-use system; that is to say that it was from a forensic challenge scenario system, and not a system used in a corporate environment.  Regardless, this limited testing did allow us to see that there is considerable value in incorporating the transaction logs in our Registry parsing process.

Other images are available online which may be used to further this testing.  For example, the Mystery Hacked System image includes activity within the user profiles, and as such, may prove to be interesting and provide even more support for this process.

Finally, after merging the transaction logs, I ran some basic diff utilities against the 'dirty' and 'merged' hives, and noted that there were a number of entries that appeared in the 'merged' hive that were not visible in the 'dirty' hive.  A method for narrowing this down a bit might be to run RegRipper profiles against both, and then run text-based diff utilities against the results of each of the profile runs.

Next Steps
My next steps are to examine additional tools (specifically, Eric Zimmerman's Registry Explorer and RECmd tools) that can be used in this process, and leveraged to take advantage of the additional data within Registry transaction logs.

References
Maxim - Exploring intermediate states of a registry hive
FireEye - Digging up the past

Other Tools
Regipy - alternative tool for merging transaction logs (note: I'm working with the author...)
RegRippy - RegRipper alternative, written in Python3

Saturday, April 13, 2019

Latest Testing: The Windows Registry, pt I

I've always been interested in and fascinated with the Windows Registry, in large part due to the fact that early in my DFIR career few really seemed to have a good grasp on, or interest in, just how central it is to the Windows operating system.  By extension, the grasp, for the community at large, as to the analysis value of the Registry was underestimated.  We've seen changes to this attitude over the years, and as the migration to incorporating the Windows Registry into analysis has progressed, so has the development of techniques for deriving even more analysis value from the Registry.

Interest in the Registry as a source of data for digital analysis and incident response has waxed and waned over the years. In the late '90s while I was performing vulnerability assessments, there was considerable utility in querying the Registry from live systems in order to determine the state and attack surface of those systems.  We were looking for (and finding) active modems in systems, as well as extracting information about software versions, etc.  To a large extent, this remains true today; there is a great deal of data available in the Registry to assist in developing an understanding of not only the state of the system at a given time, but also activity that occurred on the system.

In 2008, Jolanta Thomassen shared her dissertation regarding parsing Windows Registry hive file unallocated space; that is, retrieving deleted keys and values from unallocated space within the hive file itself.  She also released regslack.exe, a command line tool for extracting deleted keys and values from hive files.  Other tools have followed suit, providing similar functionality. Eventually, RegRipper included this functionality, as well.

In the past couple of years, attention has turned to Registry transaction logs, and incorporating data from those logs directly into hive files in order to achieve a more comprehensive and perhaps 'correct' view of the hive contents.  As such, I wanted to determine what tools were available to merge transaction logs into a hive file, and from there, begin looking at the effect of the merge operation.

I installed Python 3.7 on a Windows 10 system.  I opted for Python 3.7, as it is required for a tool I'm planning to test, Regipy.  I installed yarp on that system, as well.  This is the system I'm using as the platform for merging hives with their transaction logs.

I began testing by using yarp + registryFlush.py (thanks to Maxim) to merge the transaction logs (hive.log1, hive.log2) into a hive file, using hives from the LoneWolf scenario due in part to their availability.  Once I had successfully merged the transaction logs into the System hive, creating a 'new' System hive file, I used registry-diff.py and regdiff.pl to document the differences between the original and 'new' hives.  As an example of differences between the two hives, while they were reported by the file system to be the same size, regdiff.pl found 2561 differences between the original and 'new' hives, many of which pertained to USB devices.

I should note here that this is a very interesting finding.  Several years ago, I ran into a situation where I was comparing the System hive from a system to it's 'companion' in the RegBack folder (clearly, this goes back to when the hives in the config folder were being actively backed up).  In that case, I found 9 USB devices listed in the System hive, and 13 devices listed in the backed up hive.  I did a text search across both folders for one of the device names (one that was unique), and found an entry in one of the .log files, but at the time, there were no tools available for merging the transaction logs into the hive.

I then moved on to looking at differences in the hives via RegRipper.  Again, for this initial set of testing, I was focusing on the System hive.  As the AppCompatCache (or ShimCache) data is written to the System hive at shutdown, I did not expect to see significant differences between the two hives, and that expectation was borne out by running the appropriate plugin against both hives.  However, the BAM and Mounted Devices plugins proved to be a bit more interesting.  For example, the output of the mountdev.pl plugin run against the 'new' hive contained a drive signature for an F:\ volume that did not exist in the original hive.  The bam.pl plugin showed two additional entries for the user with RID 1001 when run against the 'new' hive.  Also, there was an entry for the Local Service account in the 'new' hive (again, via the bam.pl plugin) that was not in the original hive.

The del.pl plugin produced some interesting results.  When I ran it against the original System hive, it pulled out a number of deleted keys and values; however, running it against the 'new' (i.e., merged) hive, I got nothing.  Not one deleted key, not one deleted value.

So, what does all this mean?

I started this out wanting to simply see what tools and processes could be used to merge transaction logs into their hive file.  I posted a tweet to that effect, and Maxim was the first (and only) person to respond (to that query).  I do have additional testing to do, not just with this script, but with other tools that are available, as well.  Again, what I'm looking at here is simply how to go about merging the transaction logs into a hive, and if successful, looking to see differences between the two in order to demonstrate the value of taking these steps.

Something to keep in mind is that Windows systems no longer appear to be populating (by default) the backup copies of the Registry hives within the config/RegBack folder.  As such, merging transaction logs into the hive files prior to any parsing and analysis processes would seem to be a pretty valuable approach, if not simply provide more complete information. From that point, it's a matter of conducting analysis. 

As far as a process goes, you'd likely want to either extract the appropriate files, or mount the image with the appropriate tool such that you could access the necessary directories.  From there, you'd want to keep the original hive, and create a new version of the hive by merging the transaction logs.  The new hive would ideally give you a more complete view of the hive, but the original hive would provide you with historical information, particularly regarding deleted content.

So, more to come...

Resources
I recently became aware of RegRippy, a Python-based alternative to RegRipper.

Thursday, April 04, 2019

A Look Back...

I was chatting with someone recently with whom I'd crossed paths a bit more than 21 years ago, and throughout the time we chatted, I had this sense of nostalgia. What that led me to was the thought that when you've been in and around any industry for a while, it's interesting to take a step back and reflect on your path.

One example of nostalgia and looking back that comes about pretty regularly is when I meet former Marines.  I've met many who were anywhere between toddlers and elementary school when I left active duty, and when we talk about what we did, I have to remember that my MOS (military occupational specialty) no longer exists.  I was a Communications Officer, 2502, and the 25xx occfield is something a lot of current and former Marines have never heard of. So, nostalgia.

So, how does this relate to the cyberz? I first read The Cuckoo's Egg years ago, and thought, wow, what must it be like for Clifford and others involved to look back on what they did and the decisions they made?  What was it like to revisit the events of that time with someone else who was there, reminiscing with, "...hey, do you remember when...?"

When I started grad school in June 1994, I walked by Gary Kildall's office for about 4 months before he passed.  I never met the guy, and to be honest, would not have known who he was; I didn't find out until several years later.  At the time, I was use MS-DOS and Windows 3.1, and had transitioned to Windows 3.11 for Workgroups just prior to heading west.  I had never heard of CP/M, nor did I know much about operating systems at the time. 

While I was in grad school, OS/2 was a thing.  I went to Frye's Electronics in Sunnyvale to purchase a copy of OS/2 2.1, in part to install it on my desktop computer (with a 486DX microprocessor), but also to get the $15 off coupon sticker to apply to the purchase of OS/2 Warp 3.0.  I'd had to install a second hard drive in the computer, in part due to the fact that drives were so small back then. 

To get a sense of perspective of cost, I dropped $500 to upgrade to 16 MB (YES, with an "M") of RAM.  When you installed the second hard drive (the ribbon cables only had two connectors), you had to be sure to set the jumpers correctly.

As part of my master's thesis, I wrote an SNMP polling utility in Java.  This was just for the data collection phase of my thesis work; this was preceded by setting up a lab environment, using Windows 95 and Windows NT 3.51 servers, with two different network media (10-Base2, 10-BaseT) connected across two Cisco 2514 routers.  One of the routers was connected to the campus area network (CAN) via a 10-Base5 vampire tap.  I used simple video teleconferencing software to generate traffic across the network, and I used the SNMP polling application to collect traffic volume information over time.  Once volumes of data had been collected, I did all of the statistical processing and image display via MatLab.  To generate the traffic, I'd sit in front of one of the video cameras eating my lunch, and I'd sit in sight of the other camera.  I'd wave my arm to generate frame updates from the second camera.

As an aside, the knowledge I developed of SNMP would serve me quite well, well after I left grad school and the military.  Not only could I make recommendations to a network operations team regarding security (i.e., don't allow SNMP or even just UDP through the firewall, etc.) based on that knowledge, but I could also use what I had learned to develop information about systems during pen testing.  Yes, you'd be surprised what was accessible from the Internet back then (SNMPNetBIOS), and even later.

All of the main terminals in my graduate program were SparcStations running Solaris (NetScape was the browser we used).  I'd used TRS-80s in high school (programming PASCAL) and college (programming BASIC), and my family's first home computer was a Timex-Sinclair 1000; the second was an Epson QX-10.  During that time (early '80s) I had also taken a course in BASIC programming on the Mac IIe.  Somewhere along the line, a friend of mine had a Commodore 64, but I wasn't into playing computer games so I didn't spend much time with it.  I never did touch an Amiga, but I did take two courses in grad school that involved using assembly language to program the Motorola 68000 microprocessor.

I was in grad school when SATAN was released (circa  1995).  Shortly after it became available, I transitioned to the role of being the student rep from my academic department to the IT board.  I sat through more than a few meetings where the IT admins from across campus argued about running the scanner on each other's networks.  I never actually ran the tool; I was afraid to even download it.  This was due to the fact that I'd downloaded a copy of a file called "crack.c", in order to learn a bit more about C programming (for a course I was taking at the time).  I got in "trouble" with the senior sysadmin for the department because I had the file on my system.  I argued that I had never compiled it (part of the course was the compilation process), never created an object file, never linked it, etc.  None of that mattered to her.  Things went really sideways when she'd claimed that I had violated THE security policy; knowing that I'd never signed such a thing, I asked to see the security policy. That's when she turned red and stormed off.  Even though the two other admins were on my side, I was in the doghouse with the senior sysadmin. The fact was that it was another year before a new Admiral took of the school as superintendent and there was an actual written security policy.  Even what that policy was available, downloading crack.c would not have been a violation. 

As my active duty time ended and I was processing out of the military, I was attached to the Marine Detachment at the Army's Defense Language Institute (DLI). My role at the time was to connect the computer systems in the detachment to the Army's CAN, which was token ring. Around that time, the Commandant of the Marine Corps (Chuck Krulak) had stated that Marines were authorized to play "Marine DOOM", and the detachment had purchased 6 Gateway computer systems for that purpose.  These systems were set up on a round credenza, connected via a 10-Base2 network, running IPX.  At one point, a SSgt joined the unit and decided to make the room his office.  To make more room, he had the Marines split the credenza in half and place the flat parts against opposite walls, with 3 stations on either side of the room.  To do so, the computers needed to be disconnected.  Once everything was in place, the computers were reconnected, and attempts were made to run the game, all of which failed. As the SSgt approached me for assistance, I didn't realize until much later in life that this was my first consulting gig.  The SSgt informed me that the computer network had been reassembled EXACTLY as its previous state.  I took a look at the system at the end of the network, and realized that the RS-232 connector had been attached directly to the NIC; looking around, I found the T connector and terminator sitting under the keyboard.  No one saw me reconnect everything, but I told the SSgt to try again, and the network sprung to life.  Within minutes, the Marines were back to playing the game. 

In one of my first jobs out of the military, I was doing assessment work.  During that time, I spent time in one of the Twin Towers in New York City, doing war dialing work.  Our tools of choice were THCScan and ToneLoc. It was pretty exciting for two of us to sit in a cubicle, with the sound turned way down on the laptop we were using, listening to the responses we were getting from remote systems.  Most of the time, the phone on the other end would be answered, and we'd hear "hello" come out of the speakers. It really got exciting when we could hear software dial a number, and a phone ring two cubicles down, and the person in that cubicle respond, their "hello" echoing in the speaker of the laptop.  When the software dialed the cubicle on either side of us, we threw our jackets over the laptop to ensure that the residents didn't hear us.  We got "caught" when the software dialed phones on opposite sides of the mainframe room; the mainframe admin wasn't happy about having to get up and walk across the room apparently, and he called the CIO to report the activity. 

I later worked at Trident Data Systems (TDS), where I was doing vulnerability assessments and some light pen testing work.  We used ISS's Internet Scanner for our vulnerability assessment work, and while I was there, I began developing a tool we called "NTCAT" to replace the use of ISS's tool.  We were getting a good bit of spurious findings from Internet Scanner, most notably with respect to the Windows "AutoAdminLogon" setting, and were learning more about what Internet Scanner was doing.  That is, what data it was collecting, and how it was making it's determinations.  And this is where we were running into issues, which we were addressing using this new tool.  When I wasn't doing assessment work or writing reports, I was connected to the lab, developing and testing NTCAT.  This is also where I really started to see the value in graphic representations of data, albeit in a very simple format (i.e., red for bad, green for good).  I also began to see, up close, the value of processing data in different ways; getting a quick SWAG while you're on-site, versus a deeper inspection of the data when you had time.  Taking it a step further, we were finding out new things and developing new tools to process the data, making things more useful and valuable to the analyst, and subsequently to the customer.

One of the things I pitched to my manager at the time was that once we collected all of this data from the customer, we had it.  We'd need to address it legally, through our contracts of course, but we could keep the actual data in a secure manner (encrypted and/or stored offline on a CD), and as we learned new things, run this new processing across the retained data.  It's interesting to look back on those discussions, and then look at what we do now with respect to MSS and EDR, particularly regarding data retention times.  I've seen some of the same questions and issues from back then in today's world; few EDR tools provide a retrospective look at what happened on a system prior to the installation of the agent or sensor, and as such, IR teams have to use other means to collect this historical data.  Things brings up questions of "what do you collect?", "how do you collect it?", as well as "how long can you keep the data?"  Times have changed, technology has changed, but we still see some of the same issues.

During my time with TDS, some members of our team were working a pretty big pen test, and had run up against an Internet-connected PBX.  They really wanted to get access to this PBX, and worked hard at doing so.  At one point, several members of the team went to the loading dock on the first floor of our building for a smoke break, and were talking about what they'd run into.  On the first floor of our building was an engineering firm, one that specialized (as it turns out) in that PBX. While our guys were out on their break, one of the engineers was just finishing up a break of his own when he overheard what they were discussing.  He walked over and offered them the 15 character password that was hard-coded into the PBX. 

In another job, I worked (indirectly) for a security director who'd appeared by name in the book TakeDown.  Several years later, while I was attending a conference in Seattle, I saw Kevin Mitnick.  I didn't talk to him...he was surrounded by a mob, and I don't do mobs. Also, I wasn't really sure what I'd say. 

As time passes, I may write some additional posts, looking back on the things I've seen, as well as folks I've engaged with.  We'll see...


Thursday, March 21, 2019

A Minimal LNK

Yeah, so I've written about LNK files before, but I wanted to take it a step further and explore just how much of the specification is required for a functioning LNK file.

Step 1
I used VBS to create a "bare-bones" LNK to run calc.exe.  I like to have something visual when testing this sort of thing.

The resulting LNK file is 890 bytes in size, and here's what the metadata for the file looks like:

guid               {00021401-0000-0000-c000-000000000046}
mtime              Wed Apr 11 23:34:36 2018 Z
atime              Wed Apr 11 23:34:36 2018 Z
ctime              Wed Apr 11 23:34:36 2018 Z
basepath           C:\Windows\System32\calc.exe
shitemidlist       My Computer/C:\/Windows/System32/calc.exe
**Shell Items Details (times in UTC)**
  C:2018-04-11 21:04:34  M:2018-10-11 21:39:08  A:2018-10-11 21:39:08 Windows (9)
  C:2018-04-11 21:04:34  M:2018-12-20 22:46:22  A:2018-12-20 22:46:22 System32 (9)
  C:2018-04-11 23:34:38  M:2018-04-11 23:34:38  A:2018-04-11 23:34:38 calc.exe (9)
vol_sn              22D3-06AE
vol_type           Fixed Disk
hotkey              0x14
showcmd          0x4

***LinkFlags***
HasLinkTargetIDList|IsUnicode|HasLinkInfo|HasRelativePath

***PropertyStoreDataBlock***
GUID/ID pairs:
{446d16b1-8dad-4870-a748-402ea43d788c}/104
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       SID: S-1-5-21-3855314428-4085452759-4066589348-1000

***KnownFolderDataBlock***
GUID  : {1ac14e77-02e7-4e5d-b744-2eb1ae5198b7}
Folder: CSIDL_SYSTEM

***TrackerDataBlock***
Machine ID                   : enzo
New Droid ID Time        : Tue Sep 18 10:39:24 2018 UTC
New Droid ID Seq Num  : 7175
New Droid    Node ID     : 5c:26:0a:24:29:6f
Birth Droid ID Time       : Tue Sep 18 10:39:24 2018 UTC
Birth Droid ID Seq Num : 7175
Birth Droid Node ID       : 5c:26:0a:24:29:6f

Okay, that is a LOT of stuff that's created in an LNK file, based on the following .vbs script:

set w = CreateObject("Wscript.shell")
set l = w.CreateShortcut("\foo2.lnk")
l.TargetPath = "c:\windows\system32\calc.exe"
l.Save

Step 2
Write code that creates a bare-bones LNK file header.  By "bare-bones", I mean one with the time stamps and any extraneous metadata zero'd out.

Step 3
Write code that goes to the LNK file created in step 1, and strips out just the linktargetIDlist, or "shell item ID list".  Zero out all of the time stamps in the shell items, and just for giggles, change the version value within the shell items.  Append this linktargetIDlist to the header created in step 2.

The resulting LNK file appears below:









The LNK file is 389 bytes in size, and functions perfectly well, no matter where I put it within the file system.  I double-click it, it launches the Calculator, as expected. 

However, this is what the metadata now looks like:

guid               {00021401-0000-0000-c000-000000000046}
shitemidlist       My Computer/C:\/Windows/System32 /calc.exe
**Shell Items Details (times in UTC)**
  C:0                   M:0                   A:0                  Windows (10)
  C:0                   M:0                   A:0                  System32  (10)
  C:0                   M:0                   A:0                  calc.exe  (10)
hotkey             0x0
showcmd         0x1

***LinkFlags***
HasLinkTargetIDList|IsUnicode

The result of this process is a functioning LNK file with minimal metadata.  No disk or volume info, no SID, no MAC address, none of the things we'd look for when analyzing a weaponized LNK file.

I put some of what was used in the creation of these LNK files on GitHub.

Tuesday, March 05, 2019

Book Writing Misconceptions

You have to admit, our industry is fraught with misconceptions.  Misconceptions and misunderstandings about business practices, about what things should be versus what they really are, about what some data represents, misconceptions about how many emails some people get, and misconceptions about how "busy" people are. The list goes on. From my own perspective, I get it.  I've been in work-from-home positions since about 2006, but even when I was working in an office or "cube-farm", my world view was somewhat limited. As such, I really try to ask and find out before I make an assumption about something...I try.  That doesn't mean that I always succeed.  But I do think that it's human nature to make some assumptions about things.

From an external perspective, over the years I've received emails and messages that have started off, "...I know you're probably too busy to answer this...", but that's never been the case.  Ever.  In more than a few instances, I've responded in under an hour, and in cases where the exchange has been about RegRipper plugins, I've returned a working plugin in under an hour, and then proceeded on to provide something a bit more polished, usually in under 4 hrs.  This is simply meant to illustrate my point, that someone who doesn't have any insight into my daily work life will assume that I'm "too busy", but that's simply their perspective, developing in isolation from any meaningful input.

Okay, that being said, on to the part of this post that deals with writing books.  I'll be the first to admit that when I started down the road of publishing my first book I had what turned out to be a few pretty big misconceptions about what working with a publisher would do for me, and I'm here to share them.

Before I get started, however, let me be clear...I'm not asking for anything.  I'm not writing this in hopes of getting feedback, nor to get anyone to change what they do, nor to suddenly pick up a banner and charge forth.  Not at all.  I'm simply pulling together stuff I've had sitting around in draft form, and I thought I'd put it out there.  If this shines a light for someone, great. 

Also, I've cancelled my contract for book number 10, which was to be titled, "Practical Windows Investigations". The content of this book had been shared here and here.

Okay, then...let's go.

Book Writing
I didn't embark on this journey to obtain notoriety or fame.  I started down this road because I had found the books on my topic(s) of interest wanting...I couldn't find any books containing the content that I wanted in bookstores. As such, I decided that I wanted to put together a book that I would want to take off the shelf of a book store, and proceed to check out.  In most of the cases to that point, I had seen titles that contained the words "Windows" and "forensics", taken the book down and thumbed through it, and then put it back, dissatisfied with the content.  I did ultimately purchase several of the books, but that was because I wanted something in front of me to remind me, "not this".

You don't get rich writing books, especially books in a genre such as DFIR.  This is not a condemnation of the community, it's a simple fact.  Simply put, the topic is far too niche.  What you do get out of it is a bit of taxable income which seems great before taxes, but come March and April is another part of the paperwork that you need to be sure that you have in order.  This is not a complaint, it's simply a fact.

At one point, years ago, what I was doing and writing caught the attention of someone at Microsoft, and they used part of their team budget to provide me with an MSDN account.  This allowed me to get access to newer operating systems (this was pre-Windows 7) and applications, in order to answer questions like, "...what if you do that with the newer OS/application?"  However, he moved on from his role and there was no more interest from Microsoft, and the subscription lapsed.

Marketing
Maybe the biggest misconception I had when I started, and held even during the early days of my publishing "career", was that somehow the publishing company was going to the marketing driver for the book(s), and that they'd be wildly successful because of that.  I thought that somehow, maybe at some point, I'd write something that would get the attention of Microsoft, and through those marketing efforts, I'd somehow "level up" and embark on a new and exciting career path.  Again, that was a pretty big misconception on my part.

Okay, now for a marketing "war story".  Keep in mind, I'm not a marketing person, but at one point, I was due to speak at a fairly big conference ("big", as in within the DFIR community), and I noticed that there was a total of about half a dozen folks attending that same conference who all had published titles under the publisher's imprint.  And those titles included the word, "forensics", as did the title of the conference.  I reached to the publisher and asked if there were plans to sell books at the conference.  After all, this is what one would call a "target-rich environment".  Set up a table, have books available, and have the authors come sign books after their speaking event.  While the publishing company did have a relationship with the conference vendor, it turned out that there were no plans to do anything with respect to that conference.  After a back-and-forth, and an incredulous email or two from me, the publisher decided to their credit that while they were on a family vacation in the city, they would bring a couple of boxes of books and set up a table.  All of the authors in attendance rallied, and stopped by the table at various times to sign books that had just been purchased...pick up the book from the table, pay for it, shuffle a few steps to the right and get it signed by the author, who was just speaking on the podium a few minutes ago.  By the time the event was complete, the publisher had only a few books left.

I never understood why this had not been part of the plan.  When I had asked about the marketing plan for previous books, I was told at one point that the publisher had a list of 101 "big names in the industry", to whom they would send books and hope for a review.  I got the list and noted that most of the names on the list had no interest in host-based, nor Windows, digital forensic analysis.

The publisher does not ask me about attending conferences for book signings.  Sounds cool, I know, but it's not something that was done.  Would it make sense for the publisher's marketing department to contact authors about conferences focused on the community (digital forensics, IR, threat response/intel, etc.), maybe help get them a speaking slot, and then have those speakers spend time at the publisher's table signing books?  Yes, it would...but perhaps due to very limited marketing budgets, it doesn't happen as much as you'd think.  Again, a big misconception on my part.

In my experience, all of the marketing for published books needs to be done by the author, through whatever social media networks they have.  The other step I've taken to promote the books is, over time, I've developed a position where I've been able to negotiate some changes to the default contract; one of them has been the number of complimentary copies of books I receive.  When I get them, I then send signed copies to those folks in the industry who've had the greatest impact on the book being published, and others I give away.

Follow-on Editions
Another misconception of mine, based on the language in the contracts I signed, was that the publisher might "find value" in a book and come to me about writing a follow-on edition to a book.  It turns out that this was never the case.  WFA 2/e?  That was something I pushed, as it was with editions 3 and 4.  The same was true with WRF 2/e.  None of the follow-on editions were the result of the publisher coming to me and suggesting/requesting the new edition, due to the success of the previous edition or requests they'd received that a follow-on was needed/due, etc. 

Similarly, the creation of follow-on editions hasn't been something that's been requested or pushed by the community.  For the most part, if an edition needs to be updated, if anyone contacts me about it, that's all they say.  "It's out of date", or "it needs to be updated".  When I ask for specifics, along the lines of "where would you like it to go?" or "what topics would you like to see addressed?", that's where the exchange comes to a grinding halt.

Another aspect of the follow-on editions that likely led to a drop in sales was a move to standardized cover art.  As a concept, this was a good idea, but the execution led to considerable confusion.  What happened was that most of the titles used similar cover formatting, and while the words were different, the colors were similar.  For example, only two shades of green were used, so when I took copies of the newly published Windows Registry Forensics to a conference as give-aways, one of the recipients told me that he already had the book.  As it turned out, he had Windows Forensic Analysis, but the cover art and colors were so similar, he couldn't tell the difference between the two books (yes, even though the words on the book were different) without looking closely at the words.

Having copies of my books on my bookshelf, side-by-side, all with similar cover art and color looks pretty cool.  Add Brett's books right beside them and to me, it looks impressive.  However, in practice, it made the books difficult to distinguish and likely lead to missed sales, as casual observers saw the design and color, decided that they already had a copy, and moved on.

Feedback
After I had completed IWS and it had been "on the streets" for about a month or so, I received a survey from the publisher.  The questions were centered around requesting feedback regarding my experience with the production of the book.  Well, I'll tell you that my responses and comments were not what one would call "glowing", and at the end of the survey, I checked the box, "yes, I would be willing to discuss my responses...".  I never heard back.  This was my ninth published book, albeit the first under this particular publisher (this one had purchased my previous publisher).  I assumed (incorrectly, again, it seems) that my considered comments would have some level of credibility, and that sending me the survey was something more than simply pro forma and rote.

Royalties
Guess what?  Writing DFIR books does not get you to a point where you can retire as soon as your first book is published.  Or even your second or third.  Lots of folks in the community assume that because they enjoyed the book or because they have the book, everyone has it and the author is living in a mansion between Dean Koontz and Stephen King.  Nothing could be further from the truth.

While I'm happy that several of my books have been translated into foreign languages (looks good on my bookshelf), the fact of the matter is that in one case, I made $20 on the deal.  Before taxes.  Publishers sell the right to translate the book for a set fee, and the author gets a royalty on that fee, not on each of the books actually sold in that language.  No, this wasn't a shock to me, as I'd read the contract.  Honestly, I hadn't expected any of the books to be translated into another language.  I'm simply sharing this to clear up a misconception.

Conclusion
After all of this, I had to ask myself, why am I signing over my intellectual property to someone who's not really interested in it, has no interest in supporting the continued development of it, and at the end of the day just made it harder than it needed to be to get a book published.

I've tried three times over the years to get the publishing company I was working with to move in a direction that made the process for authors in the DFIR community a lot smoother to get a book published, from cradle to grave.  The plan I laid out cost the publisher nothing to implement, and the first time I brought it up there were a lot of misconceptions; it seemed that the publisher could not fathom the idea, and filled in what they saw as "gaps" with assumptions.  By the time I got the editor on my side and championing the idea, she left the company and I had to start all over again.  I realize that you can't change a 500 year old business model overnight, and I wasn't trying to, but it became clear that the publisher did not want to move in the direction of increasing the number and quality of DFIR books they were publishing, so why bother?

My thought was that I could act as a liaison for new authors, to help them understand the process and set expectations, and help them overcome some of the hurdles they would encounter.  In short, to help new authors get published and ultimately have a wider range of material and topics covered and available.

The Community
There's another side to this that isn't talked about, and it's the misconception(s) held by the vast majority of the "community".   Most of the folks I've engaged with over the years seem to have the belief that if someone gets a book published that they're somehow "famous", an "expert", and far "too busy" to be bothered with a call or an email.  That "busy", in their minds, seems to translate into "rolling in work".  "Busy" is a badge of honor that many seek out, but I've been working pretty hard over the past year to abolish my own use of the word, even in casual conversation.  This is due to the fact that even if I'm working hard on something...a report, creating the smallest weaponized LNK file possible, whatever...sometimes taking a break to either address a request or tell them I'll reply later is a good distraction.

The honest truth is that I'm somehow "famous" or a "rock star" simply not the case.  I still have to apply for jobs, just like everyone else.  I still have to submit to CfPs to speak at conferences, just like everyone else.  I do not get calls or requests to perform actual analysis work, and at one point (right after my third book was published), I was literally turned down for a job simply because I had published books.  That's right; I was told, "...we can't afford you...", even though we had not gotten to the part of the interview process where we were discussing compensation, and HR hadn't even asked me about my current salary.

Several years ago, I was contacted by an attorney via LinkedIn, and asked to do some work, which I did pro bono.  I wasn't the first, nor only person contacted, but I was likely the first one to respond.  It was a fascinating case (because it was real world) and the result was that based on my report, the judge decided to drop the case.  The fact is that the person who reached to me had no idea who I was, and had simply taken a chance on contacting me based on my social media profile.

My point is simply that I've been told many, many times that someone did not reach out to me because they thought I was "too busy".  This is true no matter how many times I've dispelled that myth.  In some cases, I've turned a request for a new RegRipper plugin (or an update to an older one) around in an hour, and returned something a bit more polished in four hours.  I've answered questions, responded to emails, and been on phone calls...when asked.

Sunday, February 24, 2019

LNK Files

Update, 28 Feb: Just a quick note...this post is not about tools.  I do not mention any tools in the post, and the content isn't about one tool being better than another. I do mention using a hex editor, but that is simply to verify finds from whichever tool is used.  In the first example below, every parsing tool available would've returned the exact same time stamps, and I would have (and recommended) used a hex editor to confirm the finding. At the time I'm writing this update, this post has been viewed 1258 times, and not one question about tools has been posted as a comment. This post is about LNK file metadata, what it means, and how it can be used in analysis. Thanks.

I know, I know...yet another blog post on LNK files...yeah.  I get it.  But some new things popped up recently that I wanted to take advantage of, and they ended up here.

I had an opportunity to look at several LNK files recently, and I wanted to dig a bit deeper into their metadata.  Most available write-ups make mention of the LNK file, but tend to gloss over the file and move right to the embedded command and the next stage download.  I wanted to take a closer look at what's in the LNK file, because after all, this is something created within the adversary's environment that they're sending out.  In a lot of ways, it's like free money, so why not make the best use of what you have available, and squeeze every little bit out of the data that you have?  Maybe it's just me, but when the adversary gives you something, it's hardly a "little bit".

Consider this: several years ago, the folks at JPCERT/CC said that LNK files give us a view into the attacker's development environment; this was, and still is, a great idea, so let's see if we can not only replicate what they did (with respect to metadata extraction) but also see if we can't squeeze just a bit more out of the files, and see  what we can learn about the adversary's development environment, and maybe even see what we can learn about the tools they use to create the LNK files.

Steroids
I ran across two write-ups on LNK files recently; perhaps it would be more correct to say two write-ups on the same (or very similar) LNK file.  I found this write-up at D3xt3r's Malware Lab (blog includes a hash), and this write-up on Max's blog (blog includes a link to download the sample).  While D3xt3r's write-up is dated 16 Feb 2019, Max's doesn't have a date as part of the published material, but it does appear to have been published in Feb 2019, as well.  This is to say that they're both fairly recent posts, and as such, the LNK file itself may be fairly recent, as well.

Anyway, I wanted to take a look at a few things associated with the LNK file metadata that weren't discussed in either blog post, specifically what we could learn by going really deep in parsing the files.  One of the first things that I looked at was the shell item ID list, shown below:

shitemidlist       My Computer/C:\/Windows/system32/cmd.exe
**Shell Items Details (times in UTC)**
  C:0                   M:0                   A:0                  Windows (8)
  C:0                   M:0                   A:0                  system32 (8)
  C:0                   M:0                   A:0                  cmd.exe (8)

As we can see from the above output, I parsed the shell item ID list, but the time stamps embedded within the individual shell items (the creation, modification, and last accessed times of the resources) appear to all be zeros.  Using a hex editor, I verified this quite easily, and in fact, the bytes at the locations for the time stamps within each of the shell items are all zeros.  Interestingly enough, the LNK file mentioned here also has the shell item time stamps zero'd out, so this is likely not a unique finding.  However, it's unclear whether this is the result of the tool used to create the LNK file, or of anti-forensic/obfuscation efforts taken after the LNK file was created.

We also see that the version information for the shell items is "8", indicating that the platform is Windows 2008, 7, or 8 (per section 6.5 here).  This gives us some additional (beyond what the JPCERT/CC folks discussed) insight into the development environment used by the adversary.

Now, let's take a look at the contents of the PropertyStoreDataBlock, shown below:

***PropertyStoreDataBlock***
GUID/ID pairs:
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       
         SID: S-1-5-21-1243223150-2135741377-3118647425-500
{f29f85e0-4ff9-1068-ab91-08002b27b3d9}/6

As we can see,there are two GUID/ID pairs, the first of which points to a Unicode string that is a SID.  This is fairly common, in that we not only see the GUID/ID pair populated with a SID in a good number of LNK files, but we can use native tools (PowerShell, etc.) on Windows systems to create LNK files that contain this property set.  In this instance, the RID points to the default Administrator account for the system.  For the second property, the GUID indicates that it's a Summary Information Property Set, and the ID indicates that it's a comment.  Looking at the contents of the property set itself (via a hex editor), there don't appear to be any visible strings.

Interestingly, the LNK file does not appear to have a TrackerDataBlock, and as such, there is no machine ID (system NetBIOS name) embedded in the LNK file.  Again, this is pretty easy to verify via a hex editor.

What we have so far is a pretty interesting view into the manufacture of this LNK file.  There are some 'normal' elements of the file structure that exist, and there are other elements that we expect to see, but have been removed.  This is only one file, so without more insight, anything regarding the "why" is simply speculation and assumption.  What we do know at the moment is that steps were taken, either during the manufacturing process or afterward, to remove elements of the file structure, and the removal of those elements did not impact the function of the LNK file itself.

Finally, the D3xt3r post also includes a link (no pun intended) to this TrendMicro post from 2017.  The TM post indicates that, at the time, the use of LNK files to download malware was a "rising trend".

Cb
I also ran across this write-up from Carbon Black, dated 11 Feb 2019. The LNK file discussed in the Cb blog post contains some interesting metadata.  For example, this file happens to contain a description field, as shown below:

description        AVI

I can't say that I've often seen a description field within an LNK file that's been populated.  However, I should note that the LNK file from the 2018 campaign described here did have a description field of "ds7002.pdf"; the LNK file from the 2016 campaign did not.

In addition, we can see from the shell item ID list (below) that the shell items contain time stamps, and that the version numbers embedded within the shell items indicate that the system is a Windows 8.1 or 10 system.

shitemidlist       My Computer/C:\/Windows/System32/WindowsPowerShell/v1.0/powershell.exe
**Shell Items Details (times in UTC)**
  C:2018-04-11 21:04:34  M:2018-11-16 21:29:56  A:2018-11-16 21:29:56 Windows (9)
  C:2018-04-11 21:04:34  M:2018-11-21 17:32:02  A:2018-11-21 17:32:02 System32 (9)
  C:2018-04-11 23:38:22  M:2018-04-11 23:38:22  A:2018-06-28 23:05:46 WindowsPowerShell (9)
  C:2018-04-11 23:38:22  M:2018-06-28 23:04:20  A:2018-06-28 23:04:20 v1.0 (9)
  C:2018-04-11 23:35:28  M:2018-04-11 23:35:28  A:2018-04-11 23:35:28 powershell.exe (9)

Looking at the PropertyStoreDataBlock (below), we see a SID, as well as another property.

***PropertyStoreDataBlock***
GUID/ID pairs:
{446d16b1-8dad-4870-a748-402ea43d788c}/104
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       
    SID: S-1-5-21-1607665944-3235443811-1991609163-1001

Looking at the SID, we see that in this case, the RID is "1001", indicating a user account was used to create the LNK file (as opposed to the built-in administrator account, with a RID of 500).  In fact, we know from the RID that this was the second user account created on the system.

Looking up the other GUID, it appears to be a System.VolumeID property; I'm still looking for information on how to parse this property field.

Finally, we have the TrackerDataBlock (below):

***TrackerDataBlock***
Machine ID                     : x10-slim
New Droid ID Time         : Sun Jul 29 22:57:38 2018 UTC
New Droid ID Seq Num  : 5969
New Droid    Node ID     : e8:9e:b4:3a:a3:ea
Birth Droid ID Time         : Sun Jul 29 22:57:38 2018 UTC
Birth Droid ID Seq Num  : 5969
Birth Droid Node ID        : e8:9e:b4:3a:a3:ea

As we can see from the TrackerDataBlock, the NetBIOS name of the system on which the LNK file was created is "x10-slim". Looking up the MAC address OUI (i.e., e8:9e:b4) indicates that it belongs to "Hon Hai Precision Ind. Co.,Ltd.", which was also mentioned in the JPCERT/CC article. Through the course of discussions of "toolmarks", one of the topics that came up was that a common virtual machine may be used by actors; the fact that a VM is used is supported by the OUI lookup, but something that hasn't been addressed is how common this may be.

RAT
I also ran across a Proofpoint blog post from August 2017 that was very interesting, and not just because of the use of Game of Thrones as the lure.  In this particular case, the LNK file was embedded within the .docx lure file

First, let's take a look at the shell item ID list (below):

shitemidlist       My Computer/C:\/WINDOWS/system32/WindowsPowerShell/v1.0/powershell.exe
**Shell Items Details (times in UTC)**
  C:2006-05-22 17:08:04  M:2007-12-06 05:29:12  A:2007-12-06 05:29:12 WINDOWS (3)
  C:2006-05-22 17:08:04  M:2007-12-04 00:44:06  A:2007-12-04 00:44:06 system32 (3)
  C:2007-09-21 00:56:32  M:2007-09-21 00:56:32  A:2007-09-21 00:56:32 WindowsPowerShell (3)
  C:2007-09-21 00:56:32  M:2007-12-03 06:20:46  A:2007-12-03 06:20:46 v1.0 (3)
  C:2009-07-13 23:49:08  M:2009-07-14 01:39:22  A:2009-07-13 23:49:08 powershell.exe (8)

In this case, the version of "3" from the shell items indicates a Windows XP or 2003 system.  And yes, I did catch (and verify) that the version info for the final shell item ("powershell.exe") is indeed "8".  This seems to indicate that the LNK file was created on an older platform.

Skipping past the encoded Powershell command, we see a couple of times of interest.  First, the PropertyStoreDataBlock (below):

***PropertyStoreDataBlock***
GUID/ID pairs:
{0c570607-0396-43de-9d61-e321d7df5026}/3
{46588ae2-4cbc-4338-bbfc-139326986dce}/4       
   SID: S-1-5-21-3345294922-2424827061-887656146-1000
{dabd30ed-0043-4789-a7f8-d013a4736622}/100
{b725f130-47ef-101a-a5f1-02608c9eebac}/10
{28636aa6-953d-11d2-b5d6-00c04fd918d0}/30

Okay, this LNK file has 5 items in this data block, which is unusual in itself.  We see the SID, which as with the LNK file from the Carbon Black post, is for a user account.  We also see a number of other GUID/ID pairs, as well, and I think that this may be the result of the EnableTargetMetadata flag having been set in the LNK file.  I say this because if you read the description of the flag (here), it says:

The shell link attempts to collect target properties and store them in the PropertyStoreDataBlock (section 2.5.7) when the link target is set.

I'm not 100% clear on what this means, but it seems to say that target properties are stored when the target of the LNK file is "set".  I guess maybe another question to consider is, was the flag specifically set, and if so, what tool or application was used to create the LNK file?

Moving on, we see that this particular LNK file has a code page value identified in the metadata, as shown below:

***ConsoleFEDataBlock***
Code page: 936

The code page is identified as "simplified Chinese", which makes sense because the campaign was thought to have a Chinese nexus.  However, what I have to wonder is how many times a code page is seen within LNK files.  For example, neither of the LNK files discussed here appeared to contain code pages.  I rarely see write-ups that mention LNK files that also mention a code page entry.

Is it possible that this field was modified as a "false flag" or "red herring"?  Sure.  When looking at any single metadata field with a file structure in isolation, the possibility exists that it was modified.  We've seen evidence, just in this blog post, of either a manufacturing process that creates the files in the state that we see them, or an "after market" process that removes the missing elements from the file structure.  But what we're not seeing is the exploration of these findings in the context of the larger campaign.  Are the actors creating other "false flags"?  If so, how pervasive are they?  Are the LNK file elements linked to other campaigns, possibly even ones associated with different actors?

Finally, the TrackerDataBlock contains a machine ID of "john-win764".  Used in conjunction with the SID and volume serial number (in this case, "CC9C-E694"), a VirusTotal retro-hunt might turn up other examples of similar LNK files.

Final Thoughts
Some thoughts come to mind as a result of looking at these files.  First off, there's a good bit of metadata that can be used to do research on campaigns, particularly through individual archives, as well as VirusTotal (re: retro-hunt).

I know some folks have said, "...yeah, but it's easy to change those fields...".  Sure, I agree to an extent, but there would be a 'cost' associated with that.  The Proofpoint team addressed this in their post.  However, what I'm referring to is parsing files already collected, ones that have been archived by teams following the campaigns and collecting data, or are available from other archival sources (VirusTotal, etc.).  If those files are tied to specific campaigns, or attributed to specific actors, then you may have something there.  Not only can you see if and how the files have changed over time (like the FireEye folks did), but what if LNK files with similar metadata appear across different campaigns, and are used by different actors?  What does that tell us?

Further, what this sort of analysis shows is that there's a lot going on underneath the MITRE ATT&CK technique, specifically, "Initial Access, Spearphishing Attachment".  In fact, quite a few sub-techniques and even specific technical details seem to pop right out.  Just look at what we've seen so far; some LNK files are sent as attachments themselves, but in other cases, the LNK files are embedded in a lure document.  Embedded commands differ (WMIC, Powershell, etc.), as does the level of obfuscation and encoding. Some LNK files contain embedded commands with some serious obfuscation, while some contain no obfuscation whatsoever.  We could create an entire matrix just for weaponized attachments.

The JPCERT/CC article described some work done in clustering LNK files based on some of the available metadata around different attacks, which was very interesting.

Additional Resources
FireEye blog post, re: FIN7 - mentions LNK "toolmarks"
PodCast with Nick Carr, discussing "toolmarks"
2018 NCSC Advisory - discusses not only the use of iconfilename fields in LNK files to maintain persistence across password changes, but also includes a very basic Yara rule for detecting the 'weaponized' LNK file (I should note that none of the metadata was shared)