Links: Plugin Updates and Other Things
Plugin Updates
Mari has done some fascinating research into MS Office Trust Records and posted her findings here. Based on her sharing her findings and sample data, I was able to update the trustrecords.pl plugin. Further, Mari's description of what she had done was so clear and concise that I was able to replicate what she did and generate some of my own sample data.
The last update to the trustrecords.pl plugin was from 16 July 2012; since then, no one's used it or apparently had any issues with it or questions about what it does. For this update, I added a check for the VBAWarnings value, and added parsing of the last 4 bytes of the TrustRecords value data, printing "Enable Content button clicked" if the data is is in accordance with Mari's findings. I also changed how the plugin determines which version of Office is installed. I also made sure to update the trustrecords_tln.pl plugin accordingly, as well.
So, from the sample data that Mari provided, the output of the trustrecords.pl plugin looks like this:
**Word**
----------
Security key LastWrite: Wed Feb 24 15:58:02 2016 Z
VBAWarnings = Enable all macros
Wed Feb 24 15:08:55 2016 Z : %USERPROFILE%/Downloads/test-document-domingo.doc
**Enable Content button clicked.
...and the output of the trustrecords_tln.pl plugin looks like this:
1456326535|REG|||TrustRecords - %USERPROFILE%/Downloads/test-document-domingo.doc [Enable Content button clicked]
Addendum, 25 Feb
After publishing this blog post yesterday, there was something that I ran across in my own testing that I felt was important to point out. Specifically, when I first opened MSWord 2010 and went to the Trust Center, I saw the default Macro Settings, illustrated in the image to the right; this is with no VBAWarnings value in the Registry. Once I started selecting other options, the VBAWarnings value was created.
What this seems to indicate is that if the VBAWarnings value exists in the Registry, even if the Macro Settings appear as seen in the image above (the data for the value would be "2"), that someone specifically changed the value. So, if the VBAWarnings value doesn't exist in the Registry, it appears (based on limited testing) that the default behavior is to disable macros with a notification. If the setting is changed, the VBAWarnings value is created. If the VBAWarnings value is set to "2", then it may be that the Macro Settings were set to something else, and then changed back.
For example, take a look at the plugin output I shared earlier in this post. You'll notice that the LastWrite time of the Security key is 50 min later than the TrustRecords time stamp for the document. In this case, this is due to the fact that Mari produced the sample data (hive) for the document, and then later modified the Macro Settings because I'd reached back to her and said that the hive didn't contain a VBAWarnings value.
Something else to think about...has anyone actually used the reading_locations.pl plugin? If you read Jason's blog post on the topic, it seems like it could be pretty interesting in the right instance or case. For example, if an employee was thought to have modified a document and claimed that they hadn't, this data might show otherwise.
**end addendum**
Also, I ran across a report of malware using a persistence mechanism I hadn't seen before, so I updated termserv.pl to address the "new" key.
Process Creation Monitoring
My recent look into and description of PECapture got me thinking about process creation monitoring again.
Speaking of process creation monitoring, Dell SecureWorks recently made information publicly available regarding the AdWind RAT. If you read through the post, you'll see that the RAT infection process spawns a number of external commands, rather than using APIs to do the work. As such, if you're recording process creation events on your endpoints, filters can be created to watch for these commands in order to detect this (and other) activity.
Malicious LNK
Wait, what? Since when did those two words go together? Well, as of the morning of 24 Feb, the ISC handlers have made it "a thing" with this blog post. Pretty fascinating, and thanks to the handlers for walking through how they pulled things out of the LNK file; it looks as if their primary tool was a hex editor.
A couple of things...
First, process creation monitoring of what this "looks like" when executing would be very interesting to see. If there's one thing that I've found interesting of late is how DFIR folks can nod their heads knowingly at something like that, but when it comes to actual detection, that's another matter entirely. Yes, the blog post lists the command line used but the question is, how would you detect this if you had process creation monitoring in place?
Second, in this case, the handlers report that "the ACE file contains a .lnk file"; so, the ACE file doesn't contain code that creates the .lnk file, but instead contains the actual .lnk file itself. Great...so, let's grab Eric Zimmerman's LECmd tool, or my own code, and see what the NetBIOS name is of the system on which the LNK file was created. Or, just go here to get that (I see the machine name listed, but not the volume serial number...). But I'd like to parse it myself, just to see what the shell items "look like" in the LNK file.
As a side note, it's always kind of fascinating to me how some within the "community" will have data in front of them, and for whatever reason, just keep it. Just as an example (and I'm not disparaging the work the handlers did, but commenting on an observation...), the handlers have the LNK file, but they're not sharing the vol SN, NetBIOS name, or shell items included in the LNK file, just the command line and the embedded payload. I'm sure that this is a case of "this is what we feel is important, and the other stuff isn't...", but what happens when others find something similar? How do we start correlating, mapping and linking similar incidents if some data that might reveal something useful about the author is deemed unnecessary by some?
Like I said, not disparaging the work that the handlers did, just thinking out loud a bit.
8Kb One-Liner
There was a fascinating post over at Decalage recently regarding a single command line that was 8Kb long. They did a really good walk-through for determining what a macro was up to, even after the author took some pretty significant steps to make getting to a human-readable format tough.
I think it would be fascinating to get a copy of this sample and run it on a system with SysMon running, to see what the process tree looks like for something like this. That way, anyone using process creation monitoring could write a filter rule or watchlist to monitor for this in their environment.
From the Trenches
The "From the Trenches" stuff I've been posting doesn't seem to have generated much interest, so I'm going to discontinue those posts and move on to other things.
Mari has done some fascinating research into MS Office Trust Records and posted her findings here. Based on her sharing her findings and sample data, I was able to update the trustrecords.pl plugin. Further, Mari's description of what she had done was so clear and concise that I was able to replicate what she did and generate some of my own sample data.
The last update to the trustrecords.pl plugin was from 16 July 2012; since then, no one's used it or apparently had any issues with it or questions about what it does. For this update, I added a check for the VBAWarnings value, and added parsing of the last 4 bytes of the TrustRecords value data, printing "Enable Content button clicked" if the data is is in accordance with Mari's findings. I also changed how the plugin determines which version of Office is installed. I also made sure to update the trustrecords_tln.pl plugin accordingly, as well.
So, from the sample data that Mari provided, the output of the trustrecords.pl plugin looks like this:
**Word**
----------
Security key LastWrite: Wed Feb 24 15:58:02 2016 Z
VBAWarnings = Enable all macros
Wed Feb 24 15:08:55 2016 Z : %USERPROFILE%/Downloads/test-document-domingo.doc
**Enable Content button clicked.
...and the output of the trustrecords_tln.pl plugin looks like this:
1456326535|REG|||TrustRecords - %USERPROFILE%/Downloads/test-document-domingo.doc [Enable Content button clicked]
Addendum, 25 Feb
 |
| Default Macro Settings (MSWord 2010) |
What this seems to indicate is that if the VBAWarnings value exists in the Registry, even if the Macro Settings appear as seen in the image above (the data for the value would be "2"), that someone specifically changed the value. So, if the VBAWarnings value doesn't exist in the Registry, it appears (based on limited testing) that the default behavior is to disable macros with a notification. If the setting is changed, the VBAWarnings value is created. If the VBAWarnings value is set to "2", then it may be that the Macro Settings were set to something else, and then changed back.
For example, take a look at the plugin output I shared earlier in this post. You'll notice that the LastWrite time of the Security key is 50 min later than the TrustRecords time stamp for the document. In this case, this is due to the fact that Mari produced the sample data (hive) for the document, and then later modified the Macro Settings because I'd reached back to her and said that the hive didn't contain a VBAWarnings value.
Something else to think about...has anyone actually used the reading_locations.pl plugin? If you read Jason's blog post on the topic, it seems like it could be pretty interesting in the right instance or case. For example, if an employee was thought to have modified a document and claimed that they hadn't, this data might show otherwise.
**end addendum**
Also, I ran across a report of malware using a persistence mechanism I hadn't seen before, so I updated termserv.pl to address the "new" key.
Process Creation Monitoring
My recent look into and description of PECapture got me thinking about process creation monitoring again.
Speaking of process creation monitoring, Dell SecureWorks recently made information publicly available regarding the AdWind RAT. If you read through the post, you'll see that the RAT infection process spawns a number of external commands, rather than using APIs to do the work. As such, if you're recording process creation events on your endpoints, filters can be created to watch for these commands in order to detect this (and other) activity.
Malicious LNK
Wait, what? Since when did those two words go together? Well, as of the morning of 24 Feb, the ISC handlers have made it "a thing" with this blog post. Pretty fascinating, and thanks to the handlers for walking through how they pulled things out of the LNK file; it looks as if their primary tool was a hex editor.
A couple of things...
First, process creation monitoring of what this "looks like" when executing would be very interesting to see. If there's one thing that I've found interesting of late is how DFIR folks can nod their heads knowingly at something like that, but when it comes to actual detection, that's another matter entirely. Yes, the blog post lists the command line used but the question is, how would you detect this if you had process creation monitoring in place?
Second, in this case, the handlers report that "the ACE file contains a .lnk file"; so, the ACE file doesn't contain code that creates the .lnk file, but instead contains the actual .lnk file itself. Great...so, let's grab Eric Zimmerman's LECmd tool, or my own code, and see what the NetBIOS name is of the system on which the LNK file was created. Or, just go here to get that (I see the machine name listed, but not the volume serial number...). But I'd like to parse it myself, just to see what the shell items "look like" in the LNK file.
As a side note, it's always kind of fascinating to me how some within the "community" will have data in front of them, and for whatever reason, just keep it. Just as an example (and I'm not disparaging the work the handlers did, but commenting on an observation...), the handlers have the LNK file, but they're not sharing the vol SN, NetBIOS name, or shell items included in the LNK file, just the command line and the embedded payload. I'm sure that this is a case of "this is what we feel is important, and the other stuff isn't...", but what happens when others find something similar? How do we start correlating, mapping and linking similar incidents if some data that might reveal something useful about the author is deemed unnecessary by some?
Like I said, not disparaging the work that the handlers did, just thinking out loud a bit.
8Kb One-Liner
There was a fascinating post over at Decalage recently regarding a single command line that was 8Kb long. They did a really good walk-through for determining what a macro was up to, even after the author took some pretty significant steps to make getting to a human-readable format tough.
I think it would be fascinating to get a copy of this sample and run it on a system with SysMon running, to see what the process tree looks like for something like this. That way, anyone using process creation monitoring could write a filter rule or watchlist to monitor for this in their environment.
From the Trenches
The "From the Trenches" stuff I've been posting doesn't seem to have generated much interest, so I'm going to discontinue those posts and move on to other things.
