Post Compilation

For this post, I'll throw out a bunch of little snippets, or "post-lets", covering a variety of DFIR topics rather than one big post that covers one topic.

What's Old Is New Again
During Feb, 2016, Mari published a fascinating blog post regarding the VBAWarnings value. That was a bit more than 6 1/2 yrs ago, which in "Internet time" is several lifetimes. 

Just this past September, Avast shared a write-up of the Roshtyak component of Raspberry Robin, where they described some of the techniques used by this malware, including checking the VBAWarnings value as a means of "detecting" virtual or testing environments.

Getting PCAPs
When I've been asked on-site (or remotely), it's most often been after an incident has happened. However, that doesn't mean that I shouldn't have a means available for myself, or to share with IT admins, to collect pcaps. Having something like this readily available can be very beneficial, when you need it.

It seems that Windows 10 and above comes with a native tool for collecting network traffic data called pktmon.

Prefer Powershell? Doug Metz over at BakerStreetForensics has a solution for you.

I've used bulk_extractor to get pcaps from memory dumps; because this uses a different means for identifying network connections than Volatility, running them both is a really, REALLY good idea! So good, as a matter of fact, that I included an example of this in Investigating Windows Systems, which just shows that regardless of the version of Windows you're dealing with, the process still holds up.

Memory Analysis
Or, if you're looking for a bit more, consider bulk_extractor with record carving.

Also, if you're doing memory analysis, you might consider tools such as MemProcFS and MemProcFS-Analyzer. While I'm not a fan of a lot of the available GUI tools that folks (generally) use for analysis, this tweet from "evild3ad79" makes visualizing processes so much easier!

MOTW
MOTW, or "mark-of-the-web" is a pretty hot topic, as it should be. "MOTW" is the NTFS alternate data stream, or "ADS", attached to files downloaded from the Internet, and something we've seen expand over time. At first these were simply "zone identifier" ADSs, and contained just that...the "zone" for the downloaded file. We first saw these associated with files downloaded via IE and Outlook, and then later saw MOTW attached to files downloaded via other browsers. 

MOTW picked up steam a bit after MS announced that they were going to change the default behavior of systems running macros in Office documents downloaded from the Internet. We then saw some actors move to using archives rather than "weaponized" Office documents, and our attention shifted to archive utilities and MOTW propagation. 

For a bit of a different perspective on MOTW, Outflank published this article discussing MOTW from a red team perspective.

And, to top it all off, MS has shared information regarding how to disable the functionality (of attaching MOTW). What this does provide is an excellent opportunity for detections, both in the SOC (adding or modifying the SaveZoneInformation value) and for DFIR (checking the value).

Web Shells
Many, many moons ago (circa 2007, 2008), Chris Pogue and I were addressing investigating SQL Injection and web shells for the IBM ISS X-Force ERS team, codifying (or trying to) some basic processes for locating these attacks in a reactive, DFIR mode. We had a lot of different approaches, all of which could be addressed programmatically...things such as the first instance of a page being requested (across the history of the web server logs that you have available), the number of times a page was requested, the length of the request sent to the page, User Agents, etc. Now, all of these depended upon which fields were actually being logged, so we started with the default IIS logging fields and attempted to modify and address things from there. This way, encountering IIS logs with the fields having been modified (hopefully, added to...) or non-IIS web servers were considered "one-offs", and we found that the approach worked well. 

I learned recently that Aaron Shelmire authored a blog on this topic for Anomali; this was a great finding, not just because it lists some of the things we'd looked for, but also because Aaron and I worked together at one point. It's great to see contributions like this within the community.

Events Ripper
Not long ago, I released Events Ripper, a proof-of-concept tool based on RegRipper, in that it relies on plugins to extract and present data. The idea behind Events Ripper is to leverage what analysts are already doing to provide situational awareness and pivot points for analysis. So, when analysts are performing timeline creation (and moving to timeline analysis), they can leverage the events file they've already created to obtain insight into the system.

At this point, all of the Events Ripper plugins are based on data in an events file, from parsed Windows Event Logs (via wevtx.bat). For example, I wrote two plugins recently, mount.pl and ntfs.pl, that analysts can use to verify initial access used by Raspberry Robin; mount.pl runs through the events file looking for Microsoft-Windows-VHDMP/1 events indicating that a disk was "surfaced", and outputs a list of the VHD[X] and/or ISO files. Ntfs.pl looks for Microsoft-Windows-Ntfs/145 events to locate volumes, and map them to the drives or devices. Using these two plugins, you can get some quick insight as to how Raspberry Robin (or other malware) may have originally made it on to the system...via a USB thumb drive or ISO file delivered as an email attachment.

Interestingly enough, when I was developing and testing the mount.pl plugin, the Microsoft-Windows-VHDMP/Operational.evtx log file from my test system contained three ISO files. Checking the RecentDocs/.iso values in the Registry, I found those same three files listed, as well. 

Per a request from my esteemed co-worker Dray, all of the plugins display the system name, or names, as the case may be. It's not unusual for systems to start out as a gold image and be renamed, so you may have event records that still contain the original system name.

The Need for Instrumentation

Almost everyone likes spies, right?  Jason Bourne, James Bond, that sort of thing?  One of things you don't see in the movies is the training these super spies go through, but you have to imagine that it's pretty extensive, if they can pop up in a city that they maybe haven't been to and transition seamlessly into the environment.

The same thing is true of targeted adversaries...they're able to seamlessly blend into your environment.  Like special operations forces, they learn how to use tools native to the environment in order to get the information that they're after, whether it's initial reconnaissance of the host or the infrastructure, locating items of interest, moving laterally within the infrastructure, or exfiltrating data.

I caught this post from JPCERT/CC that discusses Windows commands abused by attackers.  The author takes a different approach from previous posts and shares some of the command lines used, but also focuses on the frequency of use for each tool.  There's also a section in the post that recommends using GPOs to restrict the use of unnecessary commands.  An alternative approach might be to track attempts to use the tools, by creating a trigger to write a Windows Event Log record (discussed previously in this post).  When incorporated into an overall log management (SEIM, filtering, alerting, etc.) framework, this can be an extremely valuable detection mechanism.

If you're not familiar with some of the tools that you see listed in the JPCERT/CC blog post, try running them, starting by typing the command followed by "/?".

TradeCraft Tuesday - Episode #6 discusses how Powershell can be used and abused. The presenters (one of whom is Kyle Hanslovan) strongly encourage interaction (wow, does that sound familiar at all?) with the presentation via Twitter.  During the presentation, the guys talk about Powershell being used to push base64 encoded commands into the Registry for later use (often referred to as "fileless"), and it doesn't stop there.  Their discussion of the power of Powershell for post-exploitation activities really highlights the need for a suitable level of instrumentation in order to achieve visibility.

The use of native commands by an adversary or intruder is not new...it's been talked about before.  For example, the guys at SecureWorks talked about the same thing in the articles Linking Users to Systems and Living off the Land.  Rather than talking about what could be done, these articles show you data that illustrates what was actually done; not might or could, but did.

So, what do you do?  Well, I've posted previously about how you can go about monitoring for command line activity, which is usually manifest when access is achieved via RATs.

Not all abuse of native Windows commands and functionality is going to be as obvious as some of what's been discussed already.  Take this recent SecureWorks post for example...it illustrates how GPOs have been observed being abused by dedicated actors.  An intruder moving about your infrastructure via Terminal Services won't be as easy to detect using command line process creation monitoring, unless and until they resort to some form of non-GUI interaction.