Wednesday, February 24, 2016

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 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 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 plugin accordingly, as well.

So, from the sample data that Mari provided, the output of the plugin looks like this:

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 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)
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 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 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., 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.


StephenB said...

I very much enjoy your posts. Thanks for the work you do and for sharing it here.

Anonymous said...

In the referenced HA report within the article from Decalage, the following process tree is shown:
cmd.exe /V /C set

Is it this what you asked for?

H. Carvey said...


Thanks, but is that it? Is that all there is?

Anonymous said...

No, the next thing is WScript.exe for executing the vb script. At least for monitoring purposes wscript executing vbs from appdata could be monitored (or block completely). Or Word starting cmd.exe.

I found the js here, most part looks the same as with Decalage's version:

H. Carvey said...

So, it sounds like the process tree would look something like this:

WINWORD.EXE /n /dde...
cmd.exe /V /C set...
wscript.exe ....

Does this look right?

If so, it would seem that the user would see something running, due to the use of wscript.exe over cscript.exe.

I'd still like to the actual process tree, with the complete set of arguments.

Anonymous said...


Thanks for your post and your shares.

I've made a few searches on the "Sysprocs" key but could'nt figure how it is a persistence mecanism. According to my understanding, a remote desktop session won't close correctly if a program launched at logon (or one of his childs) takes time to terminate because the operating system won't terminate this program automatically. Adding a value in the "sysprocs" concerning this program will allow the O.S. to automatically terminate this program when ending the session.

Do you mean that by adding a value in this key, the program will automatically be launch when a Remote Desktop session starts ?


H. Carvey said...


I'm sorry, but I don't follow your comment...what does the "Sysprocs" key have to do with this post? I'm not sure that I'm clear on the context.


Anonymous said...


Thanks for your answer.

In this post you made ​​the following remark :

"Also, I ran across a report of malware using a persistence mechanism I hadn't seen before, so I updated to address the "new" key."

You updated the "" regripper plugin ( a really great tool !)

# Plugin for Registry Ripper;
# Change history
# 20160224 - added SysProcs info"

So my comment concerns this persistence mecanism. Maybe you can give me some clarifications on this.

Thanks a lot.


H. Carvey said...


Try clicking on the link in the comment.

Also, there's a link in the header to the plugin in the "References" section that might be of help.


Thierry_Fr said...

Thanks for taking time to answer.

H. Carvey said...

Was it helpful?

Thierry_Fr said...


In fact, the problem was still there.

IMHO, the links you refer to and the links I found concerning the "Sysproc" key don't state that the programs registered in this key will be automatically launch at logon...

So I've just made a test. I add "calc.exe" in the sysprocs key of a Windows Seven computer. I connect via remote desktop but "calc" do not popup when I logon and wasn't present in the task manager.

Reading the Symantec report I identified what could be classical persistence mecanisms ( service, winlogon-notify) but I'm really not sure for the "sysprocs" key. I must admit that I don't know why this key is added by the malware. Maybe i misunderstood some point.

Thanks in advance.