Links
Ramdo
I ran across this corporate blog post regarding the Ramdo click-fraud malware recently, and one particular statement caught my eye, namely:
Documented by Microsoft in 2014, Ramdo continues to evolve to evade host-based and network-based detection.
I thought, hold on a second...if this was documented in April 2014 (2 yrs ago), what about it makes host-based detection so difficult? I decided to take a look at what some of the AV sites were saying about the malware. After all, the MSRT link indicates that the malware writes it's configuration information to a couple of Registry values, and the Win32/Ramdo.A write-up provides even more information along these lines.
I updated the RegRipper malware.pl plugin with checks for the various values identified by several sources, but because I have limited data for testing, I don't feel comfortable that this new version of the plugin is ready for release.
Book
Speaking of RegRipper plugins, just a reminder that the newly published Windows Registry Forensics 2e not only includes descriptions of a number of current plugins, but also includes an entire chapter devoted just to RegRipper, covering topics such as how to use it, and how to write your own plugins.
Timeline Analysis
The book also covers, starting on page 53 (of the softcover edition), tools that I use to incorporate Registry information into timeline analysis. I've used to this methodology to considerable effect over the years, including very recently to locate a novel WMI persistence technique, which another analyst was able to completely unravel.
Mimikatz
For those who may not be aware, mimikatz includes the capability to clear the Event Log, as well as reportedly stop the Event Service from generating new events.
Okay, so someone can apparently stop the Windows Event Log service from generating event records, and then steal your credentials. If nothing else, this really illustrates the need for process creation monitoring on endpoints.
Addendum, 14 Apr: I did some testing last night, and found that when using the mimikatz functionality to clear the Windows Event Log, a Microsoft-Windows-EventLog/1102 event is generated. Unfortunately, when I tried the "event::drop" functionality, I got an error.
Something else to keep in mind is that this isn't the only way that adversaries can be observed interacting with the Windows Event Log. Not only are native tools (wevtutil.exe, PowerShell, WMI) available, but MS provides LogParser for free.
Ghost in the (Power)Shell
The folks at Carbon Black recently posted an article regarding the use of Powershell in attacks. As I read through the article, I wasn't abundantly clear on what was meant by the adversary attempting to "cloak" attacks by using PowerShell, but due in part to the statistics shared in the article, it does give a view into how PowerShell is being used in some environments. I'm going to guess that because many organizations still aren't using any sort of process creation monitoring, nor are many logging the use of Powershell, this is how the use of Powershell would be considered "cloaked".
Be sure to take a look at the United Threat Research report described in the Cb article, as well.
I ran across this corporate blog post regarding the Ramdo click-fraud malware recently, and one particular statement caught my eye, namely:
Documented by Microsoft in 2014, Ramdo continues to evolve to evade host-based and network-based detection.
I thought, hold on a second...if this was documented in April 2014 (2 yrs ago), what about it makes host-based detection so difficult? I decided to take a look at what some of the AV sites were saying about the malware. After all, the MSRT link indicates that the malware writes it's configuration information to a couple of Registry values, and the Win32/Ramdo.A write-up provides even more information along these lines.
I updated the RegRipper malware.pl plugin with checks for the various values identified by several sources, but because I have limited data for testing, I don't feel comfortable that this new version of the plugin is ready for release.
BookSpeaking of RegRipper plugins, just a reminder that the newly published Windows Registry Forensics 2e not only includes descriptions of a number of current plugins, but also includes an entire chapter devoted just to RegRipper, covering topics such as how to use it, and how to write your own plugins.
Timeline Analysis
The book also covers, starting on page 53 (of the softcover edition), tools that I use to incorporate Registry information into timeline analysis. I've used to this methodology to considerable effect over the years, including very recently to locate a novel WMI persistence technique, which another analyst was able to completely unravel.
Mimikatz
For those who may not be aware, mimikatz includes the capability to clear the Event Log, as well as reportedly stop the Event Service from generating new events.
Okay, so someone can apparently stop the Windows Event Log service from generating event records, and then steal your credentials. If nothing else, this really illustrates the need for process creation monitoring on endpoints.
Addendum, 14 Apr: I did some testing last night, and found that when using the mimikatz functionality to clear the Windows Event Log, a Microsoft-Windows-EventLog/1102 event is generated. Unfortunately, when I tried the "event::drop" functionality, I got an error.
Something else to keep in mind is that this isn't the only way that adversaries can be observed interacting with the Windows Event Log. Not only are native tools (wevtutil.exe, PowerShell, WMI) available, but MS provides LogParser for free.
Ghost in the (Power)Shell
The folks at Carbon Black recently posted an article regarding the use of Powershell in attacks. As I read through the article, I wasn't abundantly clear on what was meant by the adversary attempting to "cloak" attacks by using PowerShell, but due in part to the statistics shared in the article, it does give a view into how PowerShell is being used in some environments. I'm going to guess that because many organizations still aren't using any sort of process creation monitoring, nor are many logging the use of Powershell, this is how the use of Powershell would be considered "cloaked".
Be sure to take a look at the United Threat Research report described in the Cb article, as well.
