Links
Revisiting Macros
Kahu Security posted this recent blog article that was pretty interesting. I thought that the trick that was used was pretty interesting, and yes, "sneaky"...but part of me was wondering what this sort of thing would "look like" within a system image. What I mean is, if you're tasked with looking at an image of a system that may have been infected via this sort of trick, what would you look for?
The first thing that jumps out at me is the warning displayed in Word, in the second figure in the post. Once the user clicks on the "Enable Content" button, a record is created within the user's MSOffice TrustRecords key. This information can be extract using the RegRipper trustrecords.pl plugin, or added to a timeline using the trustrecords_tln.pl plugin. These plugins were mentioned as part of the HowTo: Determine User Access to Files blog post from July, 2013.
Once the user clicks on the button and the macros are enabled, you'll see the other files described in the blog post created and launched within the file system. Because the command execution does not persist in memory once the process completes, this is an excellent argument for the use of tools such as Sysmon and Carbon Black.
If some of the files that are part of the infection process are deleted or time stomped, AND you can get to the system relatively quickly, a great resource for analysis is the USN change journal.
As far as recovering/extracting the actual macro itself, take a look at this blog post for some helpful hints and tools. Also, the folks at OpenDNS posted about Investigating a Malicious Attachment without Reversing.
USN Change Journal
Speaking of files being created on a system (see what I did there?), Mari has a new blog post up where she shares her experience using the USN change journal during analysis. As you can see in her excellent blog post, the USN change journal remains an excellent resource for obtaining extremely transitory information regarding system activity; while we don't know exactly which process is responsible for various files being created, we can see within a timeline when the various file system activities occurred, and this can not only provide additional context to a timeline, but it can also fill in some gaps in that timeline.
It's great that Mari is sharing her analysis experience with others, as it really helps those of us who may not have the same types of cases as she does, or those who may not approach (or "do") analysis in the same way. It's the sharing of those experiences, as well as asking questions, that builds a stronger community.
ADSs
I ran across Matt's recent blog post...what attracted my attention to it were the references ADSs and Powershell. ADSs are something I've been interested in for quite a long time, and I've included sections in my books that have discussed creating them, running code from within them, and what they "look like" to tools such as Carbon Black.
As to the post, there was an exchange on Twitter regarding the original content of the post, which centered around the use of the phrase "without touching disk"...Matt took the initiative to correct this, as you cannot create an ADS, and at the same time say that you aren't "touching disk". This is an interesting approach, and Matt's right...under most normal circumstances, at least the circumstances I encounter as an incident responder, something like this would go undetected by sysadmins. However, this is pretty trivial to address for an incident responder, using various artifacts, some that don't hang around as long (see this blog post), and others that persist for a while longer.
Registry Stuff
I recently ran across this post over on the System Forensics blog...unfortunately, as is the case with many blogs (it seems), comments are turned off, so I have to comment here...
Early on in the post, Patrick says:
Then I ran a few more well known tools and in one case didn’t see some of the entries at all, and in another case saw the entries, but no context was provided.
Interesting...which tools? Was anything done to contact the author(s)? Was any data shared so that the author(s) could make the appropriate updates?
At the end of the post, Patrick says:
If you’re simply relying on the output of a tool you’re possibly missing some good information.
He's absolutely right, which is why I strongly recommend that analysts get into the Registry when performing analysis, looking to see what's there. This is particularly true if there are any issues with tools that don't show you what you expect to see in the output.
This particular MRU isn't something I've seen before, and it is interesting...I can clearly see the value of this data. If Patrick is willing to share some test data, I'd be more than happy to update the appropriate RegRipper plugin(s). As the author of RegRipper, I'm fully aware that I don't see everything that is possible to see in the Registry, and as such, I rely on the good will of the DFIR community when it comes to sharing data so that RegRipper plugins can be created or updated. For example, Eric Zimmerman recently shared some USRCLASS.DAT hive files with me so that I could update the RegRipper shellbags.pl plugin to be able to address shell items particular to Windows 8.1; I've updated some of the new folder shell items and I'm working on the MTP device shell items. I have also taken an opportunity to run the updated plugin against a USRCLASS.DAT hive from Windows 10 TP, but the content is limited. Therefore, so is the testing.
Also, if Patrick were willing to share what it is he doesn't like about the output of some of the available tools, I'd be happy to consider making changes to RegRipper output, as appropriate.
Speaking
I submitted two responses...titles and abstracts...to the HTCIA2015 conference "call for papers", and both were accepted. The conference is in Orlando, FL, at the beginning of September. Submitting for this conference was an interesting experience, as I started by asking what the attendees might be interested in hearing or seeing, and was told, in short, "yes!" My presentation titles are "Registry Analysis" and "Lateral Movement".
For the "Lateral Movement" presentation, I plan to discuss various methods of lateral movement within an infrastructure and what they "look like", with respect to the source and destination systems. I chose this topic as an example, and was told "yes!!" Also, I've been to conferences before where topics such as this are discussed, but there's been no real discussion or presentation of what the artifacts look like on systems.
I have something of an idea at this point regarding what I'm going to talk about during the "Registry Analysis" presentation, and I'm working on crystallizing it a bit. At this point, this is going to be an advanced presentation,
My question to you is, if you were to see a 1 hr presentation entitled, "Registry Analysis", what would you hope to get out of it? What would you look for to be discussed?
Kahu Security posted this recent blog article that was pretty interesting. I thought that the trick that was used was pretty interesting, and yes, "sneaky"...but part of me was wondering what this sort of thing would "look like" within a system image. What I mean is, if you're tasked with looking at an image of a system that may have been infected via this sort of trick, what would you look for?The first thing that jumps out at me is the warning displayed in Word, in the second figure in the post. Once the user clicks on the "Enable Content" button, a record is created within the user's MSOffice TrustRecords key. This information can be extract using the RegRipper trustrecords.pl plugin, or added to a timeline using the trustrecords_tln.pl plugin. These plugins were mentioned as part of the HowTo: Determine User Access to Files blog post from July, 2013.
Once the user clicks on the button and the macros are enabled, you'll see the other files described in the blog post created and launched within the file system. Because the command execution does not persist in memory once the process completes, this is an excellent argument for the use of tools such as Sysmon and Carbon Black.
If some of the files that are part of the infection process are deleted or time stomped, AND you can get to the system relatively quickly, a great resource for analysis is the USN change journal.
As far as recovering/extracting the actual macro itself, take a look at this blog post for some helpful hints and tools. Also, the folks at OpenDNS posted about Investigating a Malicious Attachment without Reversing.
Speaking of files being created on a system (see what I did there?), Mari has a new blog post up where she shares her experience using the USN change journal during analysis. As you can see in her excellent blog post, the USN change journal remains an excellent resource for obtaining extremely transitory information regarding system activity; while we don't know exactly which process is responsible for various files being created, we can see within a timeline when the various file system activities occurred, and this can not only provide additional context to a timeline, but it can also fill in some gaps in that timeline.
It's great that Mari is sharing her analysis experience with others, as it really helps those of us who may not have the same types of cases as she does, or those who may not approach (or "do") analysis in the same way. It's the sharing of those experiences, as well as asking questions, that builds a stronger community.
ADSs
I ran across Matt's recent blog post...what attracted my attention to it were the references ADSs and Powershell. ADSs are something I've been interested in for quite a long time, and I've included sections in my books that have discussed creating them, running code from within them, and what they "look like" to tools such as Carbon Black.
As to the post, there was an exchange on Twitter regarding the original content of the post, which centered around the use of the phrase "without touching disk"...Matt took the initiative to correct this, as you cannot create an ADS, and at the same time say that you aren't "touching disk". This is an interesting approach, and Matt's right...under most normal circumstances, at least the circumstances I encounter as an incident responder, something like this would go undetected by sysadmins. However, this is pretty trivial to address for an incident responder, using various artifacts, some that don't hang around as long (see this blog post), and others that persist for a while longer.
Registry Stuff
I recently ran across this post over on the System Forensics blog...unfortunately, as is the case with many blogs (it seems), comments are turned off, so I have to comment here...
Early on in the post, Patrick says:
Then I ran a few more well known tools and in one case didn’t see some of the entries at all, and in another case saw the entries, but no context was provided.
Interesting...which tools? Was anything done to contact the author(s)? Was any data shared so that the author(s) could make the appropriate updates?
At the end of the post, Patrick says:
If you’re simply relying on the output of a tool you’re possibly missing some good information.
He's absolutely right, which is why I strongly recommend that analysts get into the Registry when performing analysis, looking to see what's there. This is particularly true if there are any issues with tools that don't show you what you expect to see in the output.
This particular MRU isn't something I've seen before, and it is interesting...I can clearly see the value of this data. If Patrick is willing to share some test data, I'd be more than happy to update the appropriate RegRipper plugin(s). As the author of RegRipper, I'm fully aware that I don't see everything that is possible to see in the Registry, and as such, I rely on the good will of the DFIR community when it comes to sharing data so that RegRipper plugins can be created or updated. For example, Eric Zimmerman recently shared some USRCLASS.DAT hive files with me so that I could update the RegRipper shellbags.pl plugin to be able to address shell items particular to Windows 8.1; I've updated some of the new folder shell items and I'm working on the MTP device shell items. I have also taken an opportunity to run the updated plugin against a USRCLASS.DAT hive from Windows 10 TP, but the content is limited. Therefore, so is the testing.
Also, if Patrick were willing to share what it is he doesn't like about the output of some of the available tools, I'd be happy to consider making changes to RegRipper output, as appropriate.
Speaking
I submitted two responses...titles and abstracts...to the HTCIA2015 conference "call for papers", and both were accepted. The conference is in Orlando, FL, at the beginning of September. Submitting for this conference was an interesting experience, as I started by asking what the attendees might be interested in hearing or seeing, and was told, in short, "yes!" My presentation titles are "Registry Analysis" and "Lateral Movement".
For the "Lateral Movement" presentation, I plan to discuss various methods of lateral movement within an infrastructure and what they "look like", with respect to the source and destination systems. I chose this topic as an example, and was told "yes!!" Also, I've been to conferences before where topics such as this are discussed, but there's been no real discussion or presentation of what the artifacts look like on systems.
I have something of an idea at this point regarding what I'm going to talk about during the "Registry Analysis" presentation, and I'm working on crystallizing it a bit. At this point, this is going to be an advanced presentation,
My question to you is, if you were to see a 1 hr presentation entitled, "Registry Analysis", what would you hope to get out of it? What would you look for to be discussed?
