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 (
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
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.
No comments:
Post a Comment