Links and Stuff
Sysmon
I've spent some time discussing MS's Sysmon in this blog, describing how useful it can be, not only in a malware testing environment, but also in a corporate environment.
Mark Russinovich gives a great use case for Sysmon, from RSA in this online PowerPoint presentation. If you have any questions about Sysmon and how useful it can be, this presentation is definitely worth the time to browse through it.
Ransomware and Computer Speech
Ransomware has been in the "news" quite a bit lately; not just the opportunistic stuff like Locky, but also what appears to be more targeted stuff. IntelSecurity has an interesting write-up on the Samsam targeted ransomware, although a great deal of the content of that PDF is spent on the code of the ransomware, and not so much the TTPs employed by the threat group. This sort of thing is a great way to showcase your RE skillz, but may not be as relevant to folks who are trying to find this stuff within their infrastructure.
I ran across a write up regarding a new type of ransomware recently, this one called Cerber. Apparently, this particular ransomware, as part of the infection, drops a *.vbs script on the system that makes the computer tell the user that its infected. Wait...what?
Well, I started looking into it and found several sites that discussed this, and provided examples of how to do it. It turns out that its really pretty simple, and depending upon the version of Windows you're using, you may have a greater range of options available. For example, per this site, on Windows 10 you can select a different voice (a female "Anna" voice, rather than the default male "David" voice), as well as change the speed or volume of the speech.
...and then, much hilarity ensued...
Document Macros
Okay, back to the topic of ransomware, some of it (Locky, for example) ends up on systems as a result of the user opening a document that contains macros, and choosing to enable the content.
If you do find a system that's been infected (not just with ransomware, but anything else, really...), and you find a suspicious document, this presentation from Decalage provides a really good understanding of what macros can do. Also, take a look at this blog post, as well as Mari's post, to help you determine if the user chose to enable the content of the MS Office document.
Why bother with this at all? That's a great question, particularly in the face of ransomware attacks, where some organizations are paying tens or hundreds of thousands of dollars to get their documents back...how can they then justify paying for a DFIR investigation? Well, my point is this...if you don't know how the stuff gets in, you're not going to stop it the next time it (or something else) gets in.
You need to do a root cause investigation.
Do not...I repeat, do NOT...base any decisions made after an infection, compromise, or breach on assumption or emotion. Base them on actual data, and facts. Base them on findings developed from all the data available, not just some of it, with the gaps filled in with speculation.
Jump Lists
One way to determine which files a user had accessed, and with which application, is by analyzing Jump Lists. Jump Lists are a "new" artifact, as of Windows 7, and they persist through to Windows 10. Eric Zimmerman recently posted on understanding Jump Lists in depth; as you would expect, his post is written from the perspective of a tool developer.
Eric noted that the format for the DestList stream on Windows 10 systems has changed slightly...that an offset changed. It's important to know and understand this, as it does affect how tools will work.
Mysterious Records in the Index.dat File
I was conducting analysis on a Windows 2003 server recently, and I found that a user account created in Dec 2015 contained activity within the IE index.dat file dating back to 2013...and like any other analyst, I thought, "okay, that's weird". I noted it my case notes and continued on with my analysis, knowing that I'd get to the bottom of this issue.
First, parsing the index.dat. Similar to the Event Logs, I've got a couple of tools that I use, one that parses the file based on the header information, and the other that bypasses the header information all together and parses the file on a binary basis. These tools provide me with visibility into the records recorded within the files, as well as allowing me to add those records to a timeline as necessary. I've also developed a modified version of Jon Glass's WebCacheV01.dat parsing script that I use to incorporate the contents of IE10+ web activity database files in timelines.
So, back to why the index.dat file for a user account (and profile) created in Dec 2015 contained activity from 2013. Essentially, there was malware on the system in 2013 running with System privileges and utilizing the WinInet API, which resulted in web browser activity being recorded in the index.dat file within the "Default User" profile. As such, when the new user account was created in Dec 2015, and the account was used to access the system, the profile was created by copying content from the "Default User" profile. As IE wasn't being used/launched via the Windows Explorer shell (another program was using the WinInet API), the index.dat file was not subject to the cache clearance mechanisms we might usually expect to see (by default, using IE on a regular basis causes the cache to be cleared every 20 days).
Getting to the bottom of the analysis didn't take days or weeks of analysis...it just took a few minutes to finish up documenting (yes, I do that...) what I'd already found, and then circling back to confirm some findings, based on a targeted approach to analysis.
I've spent some time discussing MS's Sysmon in this blog, describing how useful it can be, not only in a malware testing environment, but also in a corporate environment.
Mark Russinovich gives a great use case for Sysmon, from RSA in this online PowerPoint presentation. If you have any questions about Sysmon and how useful it can be, this presentation is definitely worth the time to browse through it.
Ransomware and Computer Speech
Ransomware has been in the "news" quite a bit lately; not just the opportunistic stuff like Locky, but also what appears to be more targeted stuff. IntelSecurity has an interesting write-up on the Samsam targeted ransomware, although a great deal of the content of that PDF is spent on the code of the ransomware, and not so much the TTPs employed by the threat group. This sort of thing is a great way to showcase your RE skillz, but may not be as relevant to folks who are trying to find this stuff within their infrastructure.
I ran across a write up regarding a new type of ransomware recently, this one called Cerber. Apparently, this particular ransomware, as part of the infection, drops a *.vbs script on the system that makes the computer tell the user that its infected. Wait...what?
Well, I started looking into it and found several sites that discussed this, and provided examples of how to do it. It turns out that its really pretty simple, and depending upon the version of Windows you're using, you may have a greater range of options available. For example, per this site, on Windows 10 you can select a different voice (a female "Anna" voice, rather than the default male "David" voice), as well as change the speed or volume of the speech.
...and then, much hilarity ensued...
Document Macros
Okay, back to the topic of ransomware, some of it (Locky, for example) ends up on systems as a result of the user opening a document that contains macros, and choosing to enable the content.
If you do find a system that's been infected (not just with ransomware, but anything else, really...), and you find a suspicious document, this presentation from Decalage provides a really good understanding of what macros can do. Also, take a look at this blog post, as well as Mari's post, to help you determine if the user chose to enable the content of the MS Office document.
Why bother with this at all? That's a great question, particularly in the face of ransomware attacks, where some organizations are paying tens or hundreds of thousands of dollars to get their documents back...how can they then justify paying for a DFIR investigation? Well, my point is this...if you don't know how the stuff gets in, you're not going to stop it the next time it (or something else) gets in.
You need to do a root cause investigation.
Do not...I repeat, do NOT...base any decisions made after an infection, compromise, or breach on assumption or emotion. Base them on actual data, and facts. Base them on findings developed from all the data available, not just some of it, with the gaps filled in with speculation.
Jump Lists
One way to determine which files a user had accessed, and with which application, is by analyzing Jump Lists. Jump Lists are a "new" artifact, as of Windows 7, and they persist through to Windows 10. Eric Zimmerman recently posted on understanding Jump Lists in depth; as you would expect, his post is written from the perspective of a tool developer.
Eric noted that the format for the DestList stream on Windows 10 systems has changed slightly...that an offset changed. It's important to know and understand this, as it does affect how tools will work.
Mysterious Records in the Index.dat File
I was conducting analysis on a Windows 2003 server recently, and I found that a user account created in Dec 2015 contained activity within the IE index.dat file dating back to 2013...and like any other analyst, I thought, "okay, that's weird". I noted it my case notes and continued on with my analysis, knowing that I'd get to the bottom of this issue.
First, parsing the index.dat. Similar to the Event Logs, I've got a couple of tools that I use, one that parses the file based on the header information, and the other that bypasses the header information all together and parses the file on a binary basis. These tools provide me with visibility into the records recorded within the files, as well as allowing me to add those records to a timeline as necessary. I've also developed a modified version of Jon Glass's WebCacheV01.dat parsing script that I use to incorporate the contents of IE10+ web activity database files in timelines.
So, back to why the index.dat file for a user account (and profile) created in Dec 2015 contained activity from 2013. Essentially, there was malware on the system in 2013 running with System privileges and utilizing the WinInet API, which resulted in web browser activity being recorded in the index.dat file within the "Default User" profile. As such, when the new user account was created in Dec 2015, and the account was used to access the system, the profile was created by copying content from the "Default User" profile. As IE wasn't being used/launched via the Windows Explorer shell (another program was using the WinInet API), the index.dat file was not subject to the cache clearance mechanisms we might usually expect to see (by default, using IE on a regular basis causes the cache to be cleared every 20 days).
Getting to the bottom of the analysis didn't take days or weeks of analysis...it just took a few minutes to finish up documenting (yes, I do that...) what I'd already found, and then circling back to confirm some findings, based on a targeted approach to analysis.