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?
7 comments:
This is probably too basic for your intent, but being new to host-based forensics, I'd like to see a high level overview of registry structure, major differences between registries of different Windows versions, and primary registry locations that contain evidence of activities examiners commonly want to know about. Maybe you could do an intro registry analysis presentation at another time.
With regards to the macro piece, there has been a lot of social engineering put into macro enabled office docs over the last year from both commodity/crime and advanced actor malware authors. As email is inspected harder, this is other avenue to bring badness to an individual or organization. I do think it's an interesting TTP change in that the reliance is now on social engineering to execute badness rather than the familiar exploitation based office docs (e.g. Embedded Shellcode).
As for your question, I think that many would benefit from a deep-dive discussion in to the NTUSER.dat hive and why it can be such a trove of information for investigating a suspect user profile.
Anonymous,
First, thanks for the comment.
...I'd like to see a high level overview of registry structure...
Can you elaborate on this? I included a high level overview in the book Windows Registry Forensics, and such things are available online. Can you share what might be done to improve what's already out there?
...major differences between registries of different Windows versions...
It's funny, I hear this question a lot, and not just with the Registry, but with respect to the Windows OSs as a whole.
What I find most interesting is that if I talk about the commonalities, that looses a lot of folks. That is, if I talk about what's remained the same between different versions, I find that most folks seem to not really have that level of understanding...so I'm left wondering where I'll be if I talk about the differences.
My question back to you, which will help me figure out how to address your request, is...how do you do Registry analysis? What's your process?
...and primary registry locations that contain evidence of activities examiners commonly want to know about.
This is perhaps the hardest question to address...because I could give an 8 hr presentation on this topic, and never once mention a single key or value that someone in the audience "commonly wants to know about". Why is that?
Here's an example...I don't do CP exams, but I have done exams where it's important to know what files (documents, images, etc.) a user accessed, and when. So there is some carry-over. However, I have talked to a lot of folks who do CP exams, and once they find the images, they're done; I've been told that some have no interest at all in the Registry contents.
So, my question back to you is, what are the types of exams you usually conduct? What are the types of things that you "commonly want to know about"?
Maybe you could do an intro registry analysis presentation at another time.
Again, thanks for your input and comments. I'm not saying it's not valuable, because it is...very much so. With only an hour available for a presentation, there's not a great deal of time to go into the basics, so I have to assume that folks attending the presentation have some knowledge of and experience with Registry analysis.
Thanks.
Jared,
Thanks for the comments.
As for your question, I think that many would benefit from a deep-dive discussion in to the NTUSER.dat hive and why it can be such a trove of information for investigating a suspect user profile.
Great stuff, thanks.
How do you currently engage with/analyze the NTUSER.DAT?
Thanks.
Hi Harlan
for those that cant attend the conference will you be sharing the presentation slides afterwards or doing blog posts based on the presentations?
in regards to your question, i would like to see other methods of persistence in the registry that can be used besides the run keys. for example such as those used by poweliks and similar malware. i know you may have covered this in a blog post but for some who may not have seen it or aren't familiar with your blog may find it useful in the presentation.
also how you can use artifacts in the registry to aid in identifying lateral movement, for example maybe showing some of your regripper plugins around rdp usage and explaining the significance of the keys.
shellbags could also be a part of the presentation, perhaps an overview of how these are relevant in incident response in terms of reviewing what an attacker accessed via RDP after identifying suspicious login activity through sniper forensics.
and maybe briefly introduce the concept of sniper forensics as some may not know what it is and how registry analysis fits into this.
ill stop rambling but hopefully anything i wrote is of use.
Daniel,
Thanks for the comments...I greatly appreciate your input and insight, particularly when it's combined with that from others...it's giving me a view into the topic that I don't usually have.
I'm going to add some thoughts that may help in the near term...but these are all great thoughts that I'll not only try to incorporate into the presentation, but also include in the second edition of "Windows Registry Forensics".
(Sidebar: see what I did there? I couldn't get any input into the book, and only got two submissions to the book contest, but asking about the presentation gives me some great stuff to include in the book...)
for those that cant attend the conference will you be sharing the presentation slides afterwards or doing blog posts based on the presentations?
in regards to your question, i would like to see other methods of persistence in the registry that can be used besides the run keys. for example such as those used by poweliks and similar malware. i know you may have covered this in a blog post but for some who may not have seen it or aren't familiar with your blog may find it useful in the presentation.
Again, I'm not saying that this isn't great input, because it is...but there are sources available...books, blogs, etc....for folks to develop a familiarity with the Registry beyond what they'd get in a one-hour presentation at a conference.
also how you can use artifacts in the registry to aid in identifying lateral movement, for example maybe showing some of your regripper plugins around rdp usage and explaining the significance of the keys.
Here is a blog post that may be of value.
shellbags could also be a part of the presentation, perhaps an overview of how these are relevant in incident response in terms of reviewing what an attacker accessed via RDP after identifying suspicious login activity through sniper forensics.
Good thought...I was planning to discuss ShellBags and their relevance.
and maybe briefly introduce the concept of sniper forensics as some may not know what it is and how registry analysis fits into this.
Again, I only have an hour...Sniper Forensics has been around long enough that one really shouldn't have to keep bringing it up in presentations.
Again, thanks...this is all great stuff.
Post a Comment