Links

RegRipper Plugin Update
Okay, this isn't so much an update as it is a new plugin.  Patrick Seagren sent me a plugin called cortana.pl, which he's been using to extract Cortana searches from the Registry hives.  Patrick sent the plugin and some test data, so I tested the plugin out and added it to the repository.

Process Creation Monitoring
When it comes to process creation monitoring, there appears to be a new kid on the block.  NoVirusThanks is offering their Process Logger Service free for personal use.

Looking at the web site, the service appears to record process creation event information in a flat text file, with the date and time, process ID, as well as the parent process ID.  While this does record some basic information about the processes, it doesn't look like it's the easiest to parse and include in current analysis techniques.

Other alternatives include native Windows auditing for Process Tracking (along with an update to improve the data collected), installing Sysmon, or going for a solution of a commercial nature such as Carbon Black.  Note that incorporating the process creation information into the Windows Event Log (via either process) means that the data can be pulled from live systems via WMI or Powershell, forwarded to a central logging server (Splunk?), or extracted from an acquired image.

Process creation monitoring can be extremely valuable for detecting and responding to things such as Powershell Malware, as well as providing critical information for responders to determine the root cause of a ransomware infection.

AirBusCyberSecurity recently published this post that walks through dynamic analysis of "fileless" malware; in this case, Kovter.  While it's interesting that they went with a pre-compiled platform, pre-stocked with monitoring tools, the results of their analysis did demonstrate how powerful and valuable this sort of technique (monitoring process creation) can be, particularly when it comes to detection of issues.

As a side note, while I greatly appreciate the work that was done to produce and publish that blog post, there are a couple of things that I don't necessarily agree with in the content that begin with this statement:

Kovter is able to conceal itself in the registry and maintain persistence through the use of several concealed run keys.

None of what's done is "concealed".  The Registry is essentially a "file system within a file", and none of what the malware does with respect to persistence is particularly "concealed".  "Run" keys have been used for persistence since the Registry was first used; if you're doing any form of DFIR work and not looking in the Run keys, well, that still doesn't make them "concealed".

Also, I'm not really sure I agree with this "fileless" thing.  Just because persistence is maintained via Registry value doesn't make something "fileless".

Ransomware and Attribution
Speaking of ransomware engagements, a couple of interesting articles have popped up recently with respect to ransomware attacks and attribution.  This recent Reuter's article shares some thoughts from analysts regarding attribution for observed attacks.  Shortly after this article came out, Val Smith expanded upon information from the article in his blog post, and this ThreatPost article went on to suggest that what analyst's are seeing is really "false flag" operations.

While there are clearly theories regarding attribution for the attacks, there doesn't appear to be any clear indicators or evidence...not that are shared, anyway...that tie the attacks to a particular group, or geographic location.

This article popped up recently, describing how another hospital was hit with ransomware.  What's interesting about the article is that there is NO information about how the bad guys gained access to the systems, but the author of the article refers to and quotes a TrustWave blog post; is the implication that this may be how the systems were infected?  Who knows?

Carving
David Cowen recently posted a very interesting article, in which he shared the results of tool testing, specifically several file carving tools.  I've seen comments and reviews from others who've read this same post that've said that David one tool or another "near the bottom", but to be honest, that doesn't appear to be the case at all.  The key to this sort of testing is to understand the strengths and "weaknesses" of various tools.  For example, bulk extractor was listed as the fastest tool in the test, but David also included the statement that it would benefit from more filters, and BE was the only free option.

Testing such as this, as well as what folks like Mari have done, is extremely valuable in not only extending our knowledge as a community, but also for showing others how this sort of thing can be done, and then shared.

Malware Analysis and Threat Intel
I ran across this interesting post regarding Dridex analysis recently...what attracted my attention was this statement:

...detail how I go about analyzing various samples, instead of just presenting my findings...

While I do think that discussing not just the "what" but also the "how" is extremely beneficial, I'm going to jump off of the beaten path here for a bit and take a look at the following statement:

...got the loader binary off virustotal...

The author of the post is clearly stating where they got the copy of the malware that they're analyzing in the post, but this statement jumped out at me, for an entirely different reason all together.

When I read posts such as this, as well as what is shared as "threat intel", I look at it from the perspective of an DF analyst and an incident responder, asking myself, "..how can I use this on an engagement?"  While I greatly appreciate the effort that goes into creating this sort of content, I also realize that very often, a good deal of "threat intel" is developed purely through open source collection, without the benefit of context from an active engagement.  Now, this is not a bad thing...not at all.  But it is something that needs to be kept in mind.

In examples such as this one, understanding that the analysis relies primarily on a malware sample collected from VT should tell us that any mention of the initial infection vector (IIV) is likely going to be speculation, or the result of open source collection, as well.  The corollary is that the IIV is not going to be the result of seeing this during an active incident.

I'll say it again...information such as this post, as well as other material shared as "threat intel"...is a valuable part of what we do.  However, at the same time, we do need to understand the source of this information.  Information shared as a result of open source collection and analysis can be used to create filters or triggers, which can then be used to detect these issues much earlier in the infection process, allowing responders to then get to affected systems sooner, and conduct analysis to determine the IIV.