Stuff

QoTD
The quote of the day comes from Corey Tomlinson, content manager at Nuix.  In a recent blog post, Corey included the statement:

The best way to avoid mistakes or become more effective is to learn from collective experience, not just your own.

You'll need to read the entire post to get the context of the statement, but the point is that this is something that applies to SO much within the DFIR and threat hunting communit(y|ies).  Whether you're sharing experiences solely within your team, or you're engaging with others outside of your team and cross-pollinating, this is one of the best ways to extend and expand your effectiveness, not only as a DFIR analyst, but as a threat hunter, as well as an intel analyst.  None of us knows nor has seen everything, but together we can get a much wider aperture and insight.

Hindsight
Ryan released an update to hindsight recently...if you do any system analysis and encounter Chrome, you should really check it out.  I've used hindsight several times quite successfully...it's easy to use, and the returned data is easy to interpret and incorporate into a timeline.  In one case, I used it to demonstrate that a user had bypassed the infrastructure protections put in place by going around the Exchange server and using Chrome to access their AOL email...launching an attachment infected their system with ransomware.

Thanks, Ryan, for an extremely useful and valuable tool!

It's About Time
I ran across this blog post recently about time stamps and Outlook email attachments, and that got me thinking about how many sources and formats for 'time' there are on Windows systems.

Microsoft has a wonderful page available that discusses various times, such as File Times.  From that same page, you can get more information about MS-DOS Date and Time, which we find embedded in shell items (yes, as in Shellbags).

If nothing else, this really reminds me of the various aspects of time that we have to consider and deal with when conducting DFIR analysis.  We have to consider the source, and how mutable that source may be.  We have to consider the context of the time stamp (AppCompatCache).  

Using Every Part of The Buffalo
Okay, so I stole that section title from a paper that Jesse Kornblum wrote a while back; however, I'm not going to be referring to memory, in this case.  Rather, I'm going to be looking at document metadata.  Not long ago, the folks at ProofPoint posted a blog entry that discussed a campaign they were seeing that seemed very similar to something they'd seen three years ago.  Specifically, they looked at the metadata in Windows shortcut (LNK) files and noted something that was identical between the 2014 and 2017 campaigns.  Reading this, I thought I'd take a closer look at some of the artifacts, as the authors included hashes for the .docx ("need help.docx") file, as well as for a LNK file in their write-up.  I was able to locate copies of both online, and begin my analysis.

Once I downloaded the .docx file, I opened it in 7Zip and exported all of the files and folders, and quickly found the OLE object they referred to in the "word\embeddings\oleObject.bin" file.  Parsing this file with oledmp.pl, I found a couple of things...first, the OLE date embedded in the file is "10.08.2017, 15:46:51", giving us a reference time stamp.  At this point we don't know if the time stamp has been modified, or what...so let's just put that aside for the moment.

Next, I at the available streams in the OLE file:

Root Entry  Date: 10.08.2017, 15:46:51  CLSID: 0003000C-0000-0000-C000-000000000046
    1 F..       6                      \ ObjInfo
    2 F..   44511                  \ Ole10Native

Hhhmmm...that looks interesting.

Excerpt of oleObject.bin file

Okay, so we see what they were talking about in the ProofPoint post...right there at offset 0x9c is "4C", the beginning of the embedded LNK file.  Very cool.

This document appears to be identical to what was discussed in the ProofPoint blog post, at figure 16.  In the figure above, we can see a reference to "VID_20170809_1102376.mp4.lnk", and the "word\document.xml" file contains the text, "this is what we recorded, double click on the video icon to view it. The video is about 15 minutes."

I'd also downloaded the file from the IOCs section of the blog post referred to as "LNK object", and parsed it.  Most of the metadata was as one would expect...the time stamps embedded in the LNK file referred to the PowerShell executable from that system, do it was uninteresting.  However, there were a couple of items of interest:

machineID               john-win764                   
birth_obj_id_node  00:0c:29:ac:13:81 (VMWare)             
vol_sn                     CC9C-E694  

We can see the volume serial number that was listed in the ProofPoint blog, and we see the MAC address, as well.  An OUI lookup of the MAC address tells us that it's assigned to VMWare interface.  Does this mean that the development environment is a VMWare guest?  Not necessarily.  I'd done research in the past and found that LNK files created on my host system, when I had VMWare installed, would "pick up" the MAC address of the VMWare interface on the host.  What was interesting in that research was that the LNK file remained and functioned correctly, long after I had removed VMWare and installed VirtualBox.  Not surprising, I know...but it did verify that at one point, when the LNK file was created, I had had VMWare installed on my system.

As a side note, I have to say that this is the first time that I've seen an organization publicizing threat intel and incorporating metadata from artifacts sent to the victim.  I'm sure that this may have been done before, and honestly, I can't see everything...but I did find this to be very extremely interesting that the authors would not only parse the LNK file metadata, but tie it back to a previous (2014) campaign.  That is very cool!

In the above metadata, we also see that the NetBIOS name of the system on which the LNK object was created is "john-win764".  Something not visible in the metadata but easily found via strings is the SID, S-1-5-21-3345294922-2424827061-887656146-1000.

This also gives us some very interesting elements that we can use to put together a Yara rule and submit as a VT retrohunt, and determine if there are other similar LNK files that originated from the same system.  From there, hopefully we can tie them to specific campaigns.

Okay, so what does all this get us?  Well, as an incident responder in the private sector, attribution is a distraction.  Yes, there are folks who ask about it, but honestly, when you're having to understand a breach so that you can brief your board, your shareholders, and your clients as to the impact, the "who" isn't as important as the "what", specifically, "what is the risk/impact?"  However, if you're in the intel side of things, the above elements can assist you with attribution, particularly when it's been developed further through not only your own stores, but also via available resources such as VirusTotal.

Ransomware
On the ransomware front, there's more good news!! 

Not only have recently-observed Cerber variants been seen stealing credentials and Bitcoin wallets, but Spora is reportedly now able to also steal credentials, with the added whammy of logging key strokes!  The article also goes on to state that the ransomware can also access browser history.

Over the past 18 months, the ransomware cases that I've been involved with have changed directions markedly.  Initially, I thought folks wanted to know the infection vector so that they could take action...with no engagement beyond the report (such is the life of DFIR), it's impossible to tell how the information was used.  However, something that started happening quite a bit was that questions regarding access to sensitive (PHI, PII, PCI) data were being asked.  Honestly, my first thought...and likely the thought of any number of analysts...was, "...it's ransomware...".  But then I started to really think about the question, and I quickly realized that we didn't have the instrumentation and visibility to answer that question.  Only with some recent cases did clients have Process Tracking enabled in the Windows Event Log...while capture of the full command line wasn't enabled, we did at least get some process names that corresponded closely to what had been seen via testing.

So, in short, without instrumentation and visibility, the answer to the question, "....was sensitive data accessed and/or exfiltrated?" is "we don't know."

However, one thing is clear...there are folks out there who are exploring ways to extend and evolve the ransomware business model.  Over the past two years we've seen evolutions in ransomware itself, such as this blog post from Kevin Strickland of SecureWorks.  The business model of ransomware has also evolved, with players producing ransomware-as-a-service.  In short, this is going to continue to evolve and become an even greater threat to organizations.

Updates

Office Maldocs, SANS Macros
HelpNetSecurity had a fascinating blog post recently on a change in tactics that they'd observed (actually, it originated from a SANS handler diary post), in that an adversary was using a feature built in to MS Word documents to infect systems, rather than embedding malicious macros in the documents.  The "feature" is one in which links embedded in the document are updated when the document is opened. In the case of the observed activity, the link update downloaded an RTF document, and things just sort of took off from there.

I've checked my personal system (Office 2010) as well as my corp system (Office 2016), and in both cases, this feature is enabled by default.

This is a great example of an evolution of behavior, and illustrates that "arms race" that is going on every day in the DFIR community.  We can't detect all possible means of compromise...quite frankly, I don't believe that there's a list out there that we can use as a basis, even if we could.  So, the blue team perspective is to instrument in a way that makes sense so that we can detect these things, and then respond as thoroughly as possible.

WMI Persistence
TrendMicro recently published a blog post that went into some detail discussing WMI persistence observed with respect to cryptocurrency miner infections.  While such infections aren't necessarily damaging to an organization (I've observed several that went undetected for months...), in the sense that they don't deprive or restrict the organization's ability to access their own assets and information, they are the result of someone breaching the perimeter and obtaining access to a system and it's resources.

Matt Graeber tweeted that on Windows 10, the creation of the WMI persistence mechanism appears in the Windows Event Logs.  While I understand that organizations cannot completely ignore their investment in systems and infrastructure, there needs to be some means by which older OSs are rolled out of inventory as they become obviated by the manufacturer.  I have seen, or known that others have seen, active Windows XP and 2003 systems as recently as August, 2017; again, I completely understand that organizations have invested a great deal of money, time, and other resources into maintaining the infrastructure that they'd developed (or legacy infrastructures), but from an information security perspective, there needs to be any eye toward (and an investment in) updating systems that have reached end-of-life.

I'd had a blog post published on my previous employer's corporate site last year; we'd discovered a similar persistence mechanism as a result of creating a mini-timeline to analyze one of several systems infected with Samas ransomware.  In this particular case, prior to the system being compromised and used as a jump host to map the network and deploy the ransomware, the system had been compromised via the same vulnerability and a cryptocoin miner installed.  There was a WMI persistence mechanism created at about the same time, and another artifact (i.e., the LastWrite time on the Win32_ClockProvider Registry key had been modified...) on the system pointed us in that direction.

InfoSec Program Maturity
Going back just a bit to the topic of the maturity of IT processes and by extension, infosec programs, with respect to ransomware...one of the things I've seen a lot of over the past year to 18 months, beyond the surge in ransomware cases that started in Feb, 2016, is the questions that clients who've been hit with ransomware have been asking.  These have actually been really good questions, such as, "...was sensitive data exposed or exfiltrated?"  In most instances with ransomware cases, the immediate urge was to respond, "...no, it was ransomware...", but pausing for a bit, the real answer was, "...we don't know."  Why didn't we know?  We had no way of knowing, because the systems weren't instrumented, and we didn't have the necessary visibility to be able to answer the questions.  Not just definitively...at all.

More recently with the NotPetya issues, we'd see where the client had Process Tracking enabled in the Windows Event Log, so that the Security Event Log was populated with pertinent records, albeit without the full command line.  As such, we could see the sequence of commands that were associated with NotPetya, and we could say with confidence that no additional commands have been run, but without the full command lines, we couldn't stated definitively that nothing else untoward had also been done.

So, some things to consider when thinking about or discussing the maturity of your IT and infosec programs include asking yourself, "...what are the questions we would have in the case of this type of incident?", and then, "...do we have the necessary instrumentation and visibility to answer those questions?"  Anyone who has sensitive data (PHI, PII, PCI, etc...) is going to have the question of "...was sensitive data exposed?", so the question would be, how would you determine that?  Were you tracking full process command lines to determine if sensitive data was marshaled and prepared for exfil?

Another aspect of this to consider is, if this information is being tracked because you do, in fact, have the necessary instrumentation, what's your aperture?  Are you covering just the domain controllers, or have you included other systems, including workstations?  Then, depending on what you're collecting, how quickly can you answer the questions?  Is it something you can do easily, because you've practiced and tweaked the process, or is it something you haven't even tried yet?

Something that's demonstrated (to me) on a daily basis is how mature the bad guy's process is, and I'm not just referring to targeted nation-state threat actors.  I've seen ransomware engagements where the bad guy got in to an RDP server, and within 10 min escalated privileges (his exploit included the CVE number in the file name), deployed ransomware and got out.  There are plenty of blog posts that talk about how targeted threat actors have been observed reacting to stimulus (i.e., attempts at containment, indications of being detected, etc.), and returning to infrastructures following eradication and remediation.

WEVTX
The folks at JPCERT recently (June) published their research on using Windows Event Logs to track lateral movement within an infrastructure.  This is really good stuff, but is dependent upon system owners properly configuring systems in order to actually generate the log records they refer to in the report (we just talked about infosec programs and visibility above...).

This is also an inherent issue with SIEMs...no amount of technology will be useful if you're not populating it with the appropriate information.

New RegRipper Plugin
James shared a link to a one-line PowerShell command designed to detect the presence of the CIA's AngelFire infection.  After reading this, it took me about 15 min to write a RegRipper plugin for it and upload it to the Github repository.

Beyond Getting Started

I blogged about getting started in the industry back in April (as well as here and here), and after having recently addressed the question on an online forum again, I thought I'd take things a step further.  Everyone has their own opinion as to the best way to 'get started' in the industry, and if you look wide enough and far enough, you'll start to see how those who post well thought out articles have some elements in common.

In the beginning...
We all start learning through imitation and repetition, because that's how we are taught.  Here's the process, follow the process.  This is true in civilian life, and it's even more true in the military.  You're given some information as to the "why", and then you're given the "how".  You do the "how", and you keep doing the "how" until you're getting the "how" right.  Once you've gotten along for a bit with the "how", you start going back to the "why", and sometimes you find out that based on the "why", the "how" that you were taught is pretty darned good.   Based on a detailed understanding of the "why", the "how" was painstakingly developed over time, and it's just about the best means for addressing the "why".

In other cases, some will start to explore doing the "how" better, or different, questioning the "why".  What are the base assumptions of the "why", and have they changed?  How has the "why" changed since it was first developed, and does that affect the "how"?

This is where critical thinking comes into play.  Why am I using this tool or following this process?  What are my base assumptions?  What are my goals, and how does the tool or process help me achieve those goals?  The worst thing you could ever do is justify following a process with the phrase, "...because this is how we've always done it."  That statement clearly shows that neither the "why" nor the "how" is understood, and you're just going through the motions.

Years ago, when I had the honor and the pleasure of working with Don Weber, he would regularly ask me "why"...why were we doing something and why were we doing it this way?  This got me to consider a lot about the decisions I was making and the actions I was taking as a team leader or lead responder, and I often found that my decisions were based not just on the technical aspects of what we were doing, but also the business aspects and the impact to the client.  I did not take offense at Don's questions, and actually appreciated them.

Learn to program
Lots of folks say it's important to learn a programming language, and some even go so far as to specify the particular language.  Thirty-five years ago, I started learning BASIC, programming on an Apple IIe.  Later, it was PASCAL, then MatLab and Java, and then Perl.  Now it seems that Python is the "de facto standard" for DFIR work...or is it?  Not long before NotPetya rocked the world, the folks at RawSec posted an article regarding carving EVTX records, and released a tool written in Go.  If you're working on Windows systems or in a Windows environment, PowerShell might be your programming language of choice...it all depends on what you want to do.

There is a great deal of diversity on this topic, and I'd suggest that the programming language you choose should be based on your needs.  The main point is that learning to program helps you see big problems as a series of smaller problems, some of which must performed in a serial fashion.  What we learn from programming is how to break bigger problems into smaller, logical steps.

Engage in the community
Within the DFIR "community", there's too much "liking" and retweeting, and not enough doing and asking of questions, nor actively engaging with others.  Not long ago, James Habben posted an excellent article on his blog on "being present", and he made a lot of important points that we can all learn from.  Further, he put a name to something that I've been aware of for some time; when presenting at a conference, there's often that one person how completely forgets that they're in a room full of other people, and kidnaps and dominates the presenter's time.  There are also those who attend the presentation (or training session) who spend the majority of their time engaged in something else entirely.

Rafal Los recently posted a fascinating article on the SecurityWeek web site.  I found his article well-considered and insightful, and extremely relevant.  It's also something I can relate to...like others, I get connection requests on LinkedIn from folks who've done nothing more than clicked a button.  I also find that after having accepted most connection requests, I never hear from the requester again.  I find that if I write a blog post (like this one) and share the link on Twitter and LinkedIn, I'll get "likes" and retweets, but not much in the way of comments.  If I ask someone what they "like" about the article...and I have done this...more often than not the response is that they didn't actually read it; they wanted to share it with their community.  Given that, there is no difference between having worked on writing and publishing the article, and not having done so.

Engaging in the community is not only a great way to learn, but also a great way to extend the community itself.  A friend recently asked me which sandbox I use for malware analysis, and why.  For me to develop a response beyond just, "I don't", I really had to think about the reasons why I don't use a sandbox.   I learned a little something from the engagement, just as I hope my friend did, as well.

An extension of engaging in the community is to write your own stuff.  Share your thoughts.  Instead of clicking "like" on a link to a blog post, add a comment to the post, or ask a question in the comments.  Instead of just clicking "like" or retweeting, share your reasons for doing so.  If it takes more than 140 characters to do so, write a blog post or comment, and share *that*.

I guess the overall point is this...if you're going to ask the question, "how do I get started in the DFIR industry?", the question itself presupposes some sort of action.  If you're just going to follow others, "like" and retweet all the things, and not actually read, engage, and think critically, then you're not really going to 'get started'.

Updates, New Stuff

Specificity
The folks at Talos recently posted an interesting article, "On Conveying Doubt".  While some have said that this article discusses "conveying doubt" (which it does), it's really about specificity of language.  Too often in our industry, while there is clarity of thought, there's a lack of specificity in the language we use to convey those thoughts; this includes all manner of communication methods; not only reports, but presentations and blog posts.  After all, it doesn't matter how good you or your analysis may be if you cannot communicate your methodology and findings.

Ransomware
Ransomware is a pretty significant issue in the IT community, particularly over the past 8 months or so.  My first real encounter with ransomware, from a DFIR perspective, started last year with a couple of Samas ransomware cases that came in; from a perspective external to my employer, this resulted in two corporate blog posts, one of which was written by a colleague/friend, and ended up being one of the most quoted and referenced blog posts published.  Interestingly enough, a lot of aspects about ransomware, in general, have continued to evolve since then, at an alarming rate.

Vitali Kremez recently posted an interesting analysis of the GlobeImposter ".726" ransomware.  From an IR perspective, where one has to work directly with clients, output from IDAPro and OllyDbg isn't entirely useful in most cases.

However, in this case, there are some interesting aspects of the ransomware that Vitali shared, specifically in section VI.(b).; that is, the command line that the ransomware executes.

Before I go any further, refer back to Kevin's blog post (linked above) regarding the evolution of the Samas ransomware.  At first, the ransomware included a copy of a secure deletion tool in one of it's resource sections, but later versions opted to reduce the overall size of the executable.  Apparently, the GlobeImposter ransomware does something similar, relying on tools native to the operating system to run commands that 'clean up' behind itself.  From the embedded batch file, we can see that it deletes VSCs, deletes user's Registry keys related to lateral movement via RDP, and then enumerates and clears *all* Windows Event Logs.  The batch file also includes the use of "taskill" to stop a number of processes, which is interesting, as several of them (i.e., Outlook, Excel, Word) would immediately alert the user to an issue.

FortiNet recently published an analysis of a similar variant.

Online research (including following #globeimposter on Twitter) indicates that the ransomware is JavaScript-based, and that the IIV is via spam email (i.e., "malspam").  If that's the case (and I'm not suggesting that it isn't), why does the embedded command line include deleting Registry keys and files associated with lateral movement via RDP?

Marco Ramilli took a look at some RaaS ransomware that was apparently distributed as an email attachment.  He refers to it as "TOPransomware", due to a misspelling in the ransom note instructions that tell the victim to download a TOP browser, as opposed to a TOR browser.  This is interesting, as some of Samas variants I've seen this year include a clear-text misspelling in the HTML ransom note page, setting the font color to "DrakRed".

I also ran across this analysis of the Shade ransomware, and aside from the analysis itself, I thought that a couple of comments in the post were very interesting.  First, "...has been a prominent strand from around 2014."  Okay, this one is new to me, but that doesn't really say much.  After all, as a consultant, my "keyhole" view is based largely on the clients who call us for assistance.  I don't claim to have seen everything and know everything...quite the opposite, in fact.  But this does illustrate the differences in perspective.

Second, "...spread like many other ransomware through email attachments..."; this is true, many other ransomware variants are spread as email attachments.  The TOPransomware mentioned previously was apparently discovered as a .vbs script attached to an email.  However, it is important to note that NOT ALL ransomware gets in via email.  This is an important distinction, as all of the protection mechanisms that you'd employ against email-borne ransomware attacks are completely useless against variants such as Samas and LeChiffre, which do not propagate via email.  My point is, if you purchase a solution that only protects you from email-borne attacks, you're still potentially at risk for other ransomware attacks.  Further, I've also seen where solutions meant to protect against email-borne ransomware attacks do not work when a user uses Chrome to access their AOL email, and the system/infrastructure gets infected that way.

On August 7, authorities in the Ukraine arrested a man for distributing the NotPetya malware (not ransomware, I know...) in order to assist tax evaders.  According to the article, he isn't thought to be the author of the destructive malware, but was instead found to be distributing a copy of the malware via his social media account so that companies could presumably infect themselves and not pay taxes.

Recently, this Mamba ransomware analysis was posted; more than anything else, this really highlights one of the visible gaps in this sort of analysis.  As the authors found the ransomware through online searches (i.e., OSINT), there's no information as to how this ransomware is distributed.  Is it as an email attachment?  What sort?  Or, is it deployed via more manual means, as has been observed with the Samas and LeChiffre ransomware?

The Grugq recently posted thoughts as to how ransomware has "changed the rules".  I started in the industry, specifically in the private sector, 20 yrs ago this month...and I have to say, many/most of the recommendations as to how to protect yourself against and recover from ransomware were recommendations from that time, as well.  What's old is new again, eh?

Cryptocurrency Miners
Cylance recently posted regarding cryptocurrency mining malware.  Figure 7b of the post provides some very useful information in the way of a high fidelity indicator..."stratum+tcp".  If you're monitoring process creation on endpoints and threat hunting, looking for this will provide an indicator on which you can pivot.  Clearly, you'll want to determine how the mining software got there, and performing that root cause analysis (RCA) will direct you to their access method.

Web Shells
The PAN guys had a fascinating write-up on the TwoFace web shell, which includes threat actor TTPs.  In the work I've done, I've most often found web shells on perimeter systems, and that initial access was exploited to move laterally to other systems within the network infrastructure.  I did, however, once see a web shell placed on an internal web server; that web shell was then used to move laterally to an MS SQL server.

Speaking of web shells, there's a fascinating little PHP web shell right here that you might want to check out.

Lifer
Retired cop Paul Tew recently released a tool he wrote called "lifer", which parses LNK files.  One of the things that makes tools like this really useful is use cases; Paul comes from an LE background, so he very likely has a completely different usage for such tools, but for me, I've used my own version of such tools to parse LNK files reportedly sent to victims of spam campaigns.

Want to generate your own malicious LNK files?  Give LNKup a try...

Supply Chain Compromises
Supply chain compromises are those in which a supplier or vendor is compromised in order to reach a target.  We've seen compromises such as this for some time, so it's nothing new.  Perhaps the most public supply chain compromise was Target.

More recently, we've recently seen the NotPetya malware, often incorrectly described as "ransomware".  Okay, my last reference to ransomware (for now...honest) comes from iTWire, in which Maersk was able to estimate the cost of a "ransomware" attack.  I didn't include this article in the Ransomware section above because if you read the article, you'll see that it refers to NotPetya.

Here is an ArsTechnica article that discusses another supply chain compromise, where a backdoor was added to a legitimate server-/network-management product.  What's interesting about the article is that it states that covert data collection could have occurred, which I'm sure is true.  The questions are, did it, and how would you detect something like this in your infrastructure?

Carving for EVTX
Speaking of NotPetya, here's an interesting article about carving for EVTX records that came out just days before NotPetya made it's rounds.  If you remember, NotPetya included a command line that cleared several Windows Event Log files

The folks who wrote the post also included a link to their GitHub site for the carver they developed, which includes not only the source code, but pre-compiled binaries (they're written in Go).  The site includes a carver (evtxdump) as well as a tool to monitor Windows Event Logs (evtxmon).

Document Metadata

Okay, yeah, so I've been blogging a lot over the past couple of months about extracting document metadata as part of gathering threat intelligence.


This handler diary provided analysis of "malspam pushing Emotet", and this follow up post illustrated how to conduct static analysis of the document itself.  I have used several of the tools mentioned, but had not yet heard of "vipermonkey", and open-source VBA emulator.  Used in conjunction with oledump.py, you can really get a lot of traction with respect to static analysis of the malicious document.

While the second handler diary post focuses on analysis of the malicious macro, what neither post does is illustrate the document metadata. Below is the output of wmd.pl, run against a sample downloaded from VT:

C:\Perl>wmd.pl d:\cases\maldoc\maldoc
--------------------
Statistics
--------------------
File    = d:\cases\maldoc\maldoc
Size    = 215040 bytes
Magic   = 0xa5ec (Word 8.0)
Version = 193
LangID  = Russian

Document has picture(s).

Document was created on Windows.

Magic Created : MS Word 97
Magic Revised : MS Word 97

--------------------
Summary Information
--------------------
Title        : sdf
Subject      : df
Authress     : admin
LastAuth     : admin
RevNum       : 2
AppName      : Microsoft Office Word
Created      : 26.07.2017, 11:51:00
Last Saved   : 26.07.2017, 11:51:00
Last Printed :

--------------------
Document Summary Information
--------------------
Organization : home

...and from oledmp.pl:

C:\Perl>oledmp.pl -f d:\cases\maldoc\maldoc -l

Root Entry  Date: 26.07.2017, 11:51:59  CLSID: 00020906-0000-0000-C000-000000000046

    1 F..   55949                      \Data

    2 F..    7359                      \1Table

    3 F..    4148                      \WordDocument

    4 F.T    4096                      \ SummaryInformation

    5 F.T    4096                      \ DocumentSummaryInformation

    6 D..       0 26.07.2017, 11:51:59 \Macros

    7 D..       0 26.07.2017, 11:51:59 \Macros\VBA

    8 FM.   88908                      \Macros\VBA\ThisDocument

    9 F..     532                      \Macros\VBA\__SRP_2

   10 F..     156                      \Macros\VBA\__SRP_3

   11 FM.    8137                      \Macros\VBA\zjUb2S

   12 FM.    8877                      \Macros\VBA\cvDTF

   13 FM.    4906                      \Macros\VBA\FX9UL

   14 F..   15451                      \Macros\VBA\_VBA_PROJECT

   15 F..     739                      \Macros\VBA\dir

   16 F..    1976                      \Macros\VBA\__SRP_0

   17 F..     198                      \Macros\VBA\__SRP_1

   18 F..      98                      \Macros\PROJECTwm

   19 F..     476                      \Macros\PROJECT

   20 F.T     114                      \ CompObj

We can see that the dates displayed by both tools line up, and we can use oledmp.pl to further list the contents (raw, or hex) of the various streams.  

So, how can any of this be of value, and why does any of this matter?  Well, at BlackHat last week, Allison Wikoff spent a great deal of her time being interviewed about some really fantastic research that she'd conducted on the "Mia Ash" persona (here is the original SecureWorks posting of the results of her research).

From the Wired article:
Eventually, Ash sent the staffer an email with a Microsoft Excel attachment for a photography survey. She asked him to open it on his office network, telling him that it would work best there. After a month of trust-building conversation, he did as he was told. The attachment promptly launched a malicious macro...

So, this really illustrates the dedication of these threat actors...they establish a persona, including social media "pocket litter", and spend time developing a relationship with their target.  As a very small part of her research, Allison took a look at the metadata embedded within the Excel spreadsheet, and found that the user information referred to "Mia Ash".  This further illustrated the depths to which the threat actors would go in order to make the persona appear authentic; not only did they populate multiple social media sites and create a "history" for the persona, but they also ensured that the metadata in the documents sent to intended victims included the 'right' contents to support the persona.  That's right, it's exactly the way it sounds...the metadata embedded in the spreadsheet specifically referred to "Mia Ash" as the authorized user of the MS Office products.

I know what you're going to say..."yeah, but that stuff can be changed/modified...".  Yes, it can...but the point is, how often is that actually done?  Look at the above listed output from wmd.pl...does it look as if any effort was put into modifying the metadata that populated the Word97 file?

Something I've said about Windows systems and DFIR work is that as the versions of Windows have been developed, the amount of information that is automatically recorded as malware or an adversary interacts with the endpoint environment has increased significantly.  In many cases, this seems to be overlooked when it comes to developing threat intelligence for some reason; in spam and phishing campaigns, a lot of the different artifacts are examined...the contents of the email (headers, body, etc.), attachment macros, second-stage downloads, etc.  But what is often missed is document metadata embedded in the attachment; Word docs, Excel spreadsheets, and even LNK shortcut files can all be rich in valuable information.  One such example is looking at time stamps...when an email was sent, when a document was created, when a binary was compiled, etc., and lining all of those up to illustrate just how organized and planned out an attack appears to be.

Tools

Today's post is a mish-mash of tools and techniques that I've seen or used recently...

Hindsight is a great free, open source tool for parsing a user's Chrome browser data.  I've used it a number of times to great effect; in one instance, I was able to show that a system became infected with ransomware when the user used Chrome to access their AOL email, where they downloaded and launched the malicious attachment.  The tool is very easy to use, and all you need to do is either point it at the user's "Default" folder (within the Chrome path), or extract the sqlite3 files and run it locally against the data.

Joe Gray over at AlienVault published an interesting article on data carving; this has always been an interesting DFIR topic, ranging from file carving to carving for individual records.  In the wake of the recent NotPetya attacks, Willi's EVTXtract might come in handy for some.  Another tool that I've run against decompressed hibernation files, pagefiles, and unallocated space is bulk_extractor, specifically when looking for indications of network communications.  My point is that if you're going to go carving, sometimes it's a good idea to first think about what it is you're carving for, and then seek an suitable approach to performing the carving.

Not "new" by any stretch, but Yogesh's research into Windows8/8.1 search history is still very relevant for a number of reasons.  For one, it illustrates the continued use of the LNK file format (which is actually pretty pervasive throughout the Windows platform...), telling us that not all of the stuff we learned from previous versions of Windows needs to be thrown out the door.  Second, Yogesh's finding that the retention mechanism for search terms changed between Windows 8 and 8.1 illustrates how quickly things can change on Windows systems.  I mean, look at what the Volatility folks have had to deal with!  ;-)

I ran across the Network Usage View tool from NIRSoft recently...that's a pretty interesting capability.  The write-up for the tool indicates that it gets it's data by reading the SRUDB.DAT database on Win8 and Win10 systems.  This is potentially a pretty valuable data source for DFIR work and analysis. In case you haven't seen it, Yogesh has a pretty fascinating presentation available on SRUM Forensics that is worth checking out.

I saw on Twitter recently that there's a Python-based tool available available now for diff'ing Registry hive files.  I completely agree with those who've commented that this is some great functionality to have available, and has a great deal of potential...but this functionality has been around from quite some time already, via other sources.  For example, James McFarlane's Parse::Win32Registry Perl module distribution includes a script that implements this functionality.  Another tool that allows you to diff two Registry hive files is RegShot.  I agree that this is great functionality to have available, particularly if you want to see what differences exist between a hive file extracted from a VSC or found in the RegBack folder, with one in the config folder.

Speaking of the Registry, I saw this paper from DFRWS 2008 that discusses recovering deleted data from Registry hive files.  My first real encounter with this sort of information was via Jolanta Thomassen's dissertation paper on the topic, and the regslack tool she provided to go along with it.  Since then, other tools (RegRipper plugins del.pl and del_tln.pl) have implemented similar functionality, largely due to the demonstrated value of this functionality.

Jason Hale posted a while back (2 yrs) on the DeviceContainers key on Windows systems, and I ran across his post again recently.  What he found is pretty interesting...I'll have to dig into it a bit more and see what else is available out there.  Jason's research seems to provide a pretty good idea of what can be derived from the key data, so this may be well worth developing a RegRipper plugin, even if just to research what's available in various hives.

I was working on some analysis recently, and was facing an issue where a good number of NTUSER.DAT files had been recovered from an image, all of which had been extracted from the image and placed in folder paths.  While there were a lot of these files, I was only interested in one Registry key (pertinent to the case), a key for which a RegRipper plugin did not exist.  So, I modified an existing plugin to give me information about the key in question, if it did exist, and then wrote a DOS batch file to iterate through all of the folders, running the new plugin (via rip.exe) against the hive file.  A few minutes of development and testing, and I had a repeatable, documented process in place and functioning, providing a capability that had not been in my hands just a few moments before.  My point in sharing this is to illustrate what can be achieved through simple problem definition, and the use of open sources to develop a solution.  I have the batch file I used, so it's pretty much self-documenting, and I pasted the command line from the batch file into my case notes.

pundup - Python script from herrcore to extract contents of McAfee *.bup files.  Even in 2017, there are a great deal of systems (and infrastructures) without any real endpoint monitoring capability employed, and sometimes you need to dig around a bit to get some really useful information about an incident.  One place you can look is AV detections (via the logs), and as such, any available quarantined files may provide even greater insight into the incident.  Further, if the system is running an older version of Windows, and you don't have an Amcache.hve file collecting process execution artifacts (like SHA-1 hashes), having the actual EXE itself to document, hash, and analyze would be very beneficial.

AppCompatProcessor - I ran across this little open source gem recently (note: according to the readme, this does not currently run on Windows); this tool runs through either AppCompatCache or AmCache data and allows you to...well, do a LOT with the data. It's well worth a look; just reading through the main page, I can easily see that a lot of what I include in my own workflow is used as pivot points, and then to expand the data.  For example, I tend to look for things like "$Recycle",

SysMon View - this is a really interesting approach to filtering and visualizing data collected by Sysmon on a Windows system.  Unfortunately, the only time I see Sysmon in use is on my own test systems; it does not seem to have been widely adopted by members of the corporate community who call for IR assistance.  I do think that this is a great approach to making better use of the data, though.

LimaCharlie - from refractionPOINT, described as an open source, cross-platform endpoint sensor.  There isn't a great deal of information available via the web page, but there are a few tweets available.

SideNote:
Speaking of endpoint agents, SANS recently conducted a product review of CrowdStrike's Falcon platform...you can get the PDF report here.
/SideNote

Invoke-Phant0m - The description states that the script "walks thread stacks of Event Log Service process (spesific[sic] svchost.exe) and identify Event Log Threads to kill Event Log Service Threads. So the system will not be able to collect logs and at the same time the Event Log Service will appear to be running."  Given the recent release of tools that claim to be able to remove individual Windows Event Log records, this is an interesting approach.  However, the biggest issue with the released tools is the inability to validate findings; while some on Twitter (I've been pointed to tweets) have claimed success, the actual EXE and process used haven't been shared to the point of allowing others to validate the findings.  To say, "...just start with this DLL..." does not provide a means of validation.

Of course, if you're not able to remove individual records, Inslainity provided another approach, albeit one that can be validated.  I've tested another approach to removing specific ranges of event records from the Security Event Log, using a method that can be scaled to all logs, but is much more insidious if you don't.

The folks at Javelin Networks have come up with an in-memory PowerShell script that can peek into consoles and provide detailed information about what's being done.  The description states that the script "extracted the content of the following command-line shells: PowerShell, CMD, Python, Wscript, MySQL Client, and some custom shells such as Mimikatz console. In some cases, the tools might be helpful to extract encrypted shells like the one used in PowerShell Empire Agent."

News
Adam (Hexacorn) has published yet another article demonstrating means of persistence and EDR bypass.  If nothing else, this is an excellent example of why endpoints of all versions (not just Windows) need to be instrumented to monitor and record process creation events, including full command lines.

Pete James over at Precision Discovery have a fascinating blog post in which he discusses records left behind in an often-overlooked Windows Event Log file.  I can't say that I've ever had a case where I've needed to know which Office files had been accessed by a user, but if you're tracking such artifact categories, then this is a good one to include.

Speaking of Office products, Will Knowles at MWRLabs published a blog post on using Office add-ins for persistence.

Here are a couple of links I've had sitting around for a while that I really haven't dug into...
Javelin Networks - CLI Powershell
NViso - Hunting Malware with Metadata
FireEye - Shim Databases used for Persistence

Analyzing Documents

I've noticed over time that a lot of the write-ups that get posted online regarding malware or downloaders delivered via email attachments (i.e., spear phishing campaign) focus on what happens after the malicious payload is activated...the URL reached to, the malware downloaded, etc.  However, few seem to dig into the document itself, and there's a great deal can be gleaned from those documents, that can add to the threat intel picture.  If you're not looking at everything involved in the incident, if you're not (as Jesse Kornblum said) using all the parts of the buffalo, then you're very likely missing critical elements of the threat intel picture.

Here's an example from MS...much of the information in the post focuses on the embedded macro and the subsequent decrypted Cerber executable file, but there's nothing available regarding the document itself.

Keep in mind that different file formats (LNK, OLE, etc.) will contain different information.  And what I'm referring to here isn't about running through analysis steps that take a great deal of time; rather, what I'm going to show you are a few simple steps you can use to derive even more information from the attachment/wrapper documents themselves.

I took a look at a couple of documents (Doc 1, Doc 2) recently, and wanted to share my process and see if others might find it useful.  Both of these OLE-format documents have hashes available (or you can download and compute the hashes yourself), and they were also found on VirusTotal:

VirusTotal analysis for Doc 1
VirusTotal analysis for Doc 2

The VT analysis for both files includes a comment that the file was used to deliver PupyRAT.

Tools
Tools I'll be using for this analysis include my own oledmp.pl and wmd.pl.

Doc 1 Analysis
Running oledmp.pl against the file, we see:

Fig. 1: Doc 1 oledmp.pl output

That's a lot of streams in this OLE file.  So, one of the first things we see is the dates for the Root Entry and the 'directories' (MS has referred to the OLE file format as "a file system within a file", and they're right), which is 1 Jan 2017.  According to VT, the first time this file was submitted was 1 Jan 2017, at approx. 20:29:43 UTC...so what that tells us is that it's likely that one of the first folks to receive the document submitted it less than 14 hrs after the file was modified.

Continuing with oledmp.pl, we can view the contents of the various streams in a hex dump format, but we see that stream number 20 contains a macro.  Using oledmp.pl with the argument "-d 20", we can view the contents of the stream in hex dump format.  In the output we see what appear to be 2 base64-encoded Powershell commands, one that downloads PupyRAT to the system, and another that appears to be shell code.  Copying and decoding both of the streams gives us the command that downloads PupyRAT, as well as a second command that appears to be some form of shell code.  Some of the variable names ($Qsc, $zw5) appear to be unique, so searching for those via Google leads us to this Hybrid-Analysis write-up, which provides some insight into what the shell code may do.

Interestingly enough, the same search reveals that, per this Reverse.IT link, both encoded Powershell commands were used in another document, as well.

Moving on, here's an excerpt of the output from wmd.pl, when run against this document:

--------------------
Summary Information
--------------------
Title        :
Subject      :
Authress     : Windows User
LastAuth     : Windows User
RevNum       : 2
AppName      : Microsoft Office Word
Created      : 01.01.2017, 06:51:00
Last Saved   : 01.01.2017, 06:51:00
Last Printed :

Notice the dates...they line up with the previously-identified dates (see fig.1)


Doc 2 Analysis
Following the same process we did with doc 1, we can see very similar output from oledmp.pl with doc 2:

Fig. 2: Doc 2 oledmp.pl output

One of the first things we can see is that this document was created within about 24 hrs of doc 1.

In the case of doc 2, stream 16 contains the data we're looking for...extracting and decoding the base64-encoded Powershell commands, we see that the commands themselves (PupyRAT download, shell code) are different.  Conducting a Google search for the variables used in the shell code command, we find this Hybrid-Analysis write-up, as well as this one from Reverse.IT.

Here's an excerpt of the output from wmd.pl, when run against this document:

--------------------
Summary Information
--------------------
Title        : HealthSecure User Registration Form
Subject      : HealthSecure User Registration Form
Authress     : ArcherR
LastAuth     : Windows User
RevNum       : 2
AppName      : Microsoft Office Word
Created      : 02.01.2017, 06:49:00
Last Saved   : 02.01.2017, 06:49:00
Last Printed : 20.06.2013, 06:27:00

--------------------
Document Summary Information
--------------------
Organization : ACC

Remember, this is a sample pulled down from VirusTotal, so there's no telling what happened with the document between the time it was created and submitted to VT.  I made the 'authress' information bold, in order to highlight it.

Summary
While this analysis may not appear to be of significant value, it does form the basis for developing a better intelligence picture, as it goes beyond the more obvious aspects of what constitutes most analysis (i.e., the command to download PupyRAT, as well as the analysis of the PupyRAT malware itself) in phishing cases.  Valuable information can be derived from the document format used to deliver the malware itself, regardless of whether it's an MSOffice document, or a Windows shortcut/LNK file.  When developing an intel picture, we need to be sure to use all the parts of the buffalo.