Monday, September 19, 2016

Links/Updates

Malicious Office Documents
Okay, my last post really doesn't seem to have sparked too much interest; it went over like a sack of hammers.  Too bad.  Personally, I thought it was pretty fascinating, and can see the potential for additional work further on down the road.  I engaged in the work to help develop a clearer threat intel picture, and there has simply been no interest.  Oh, well.

Not long ago, I found this pretty comprehensive post regarding malicious Office documents, and it covers both pre- and post-2007 formats.

What's in your WPAD?
At one point in my career, I was a security admin in an FTE position within a company.  One of the things I was doing was mapping the infrastructure and determining ingress/egress points, and I ran across a system that actually had persistent routes enabled via the Registry.  As such, I've always tried to be cognizant of anything that would redirect a system to a route or location other than what was intended.  For example, when responding to an apparent drive-by downloader attack, I'd be sure to examine not only the web history but also the user Favorites or Bookmarks; there have been several times where doing this sort of analysis has added a slightly different shade to the investigation.

Other examples of this include things like modifications to the hosts file.  Windows uses the hosts file for name resolution, and I've used this in conjunction with a Scheduled Task, as a sort of "parental control", leaving the WiFi up after 10pm for a middle schooler, but redirecting some sites to localhost.  Using that knowledge over the years, I've also examined the hosts file for indicators of untoward activity; I even had a plugin for the Forensic Scanner that would automatically extract any entries in the hosts file what was other than the default.  Pretty slick.

Not new...this one is over four years old...but I ran across this post on the NetSec blog, and thought that it was worth mentioning.  Sometimes, you just have to know what you're looking for when performing incident response, and sometimes what you're looking for isn't in memory, or in a packet capture.

Speaking of checking things related to the browser, I saw something that @DanielleEveIR tweeted recently, specifically:








I thought this was pretty interesting, not something I'd seen or thought of before.  Unfortunately, many of the malware RE folks I know are focused more on the network than the host, so things such as modifications of Registry values tend to fall through the cracks.  However, if you're running Carbon Black, this might make a pretty good watchlist item, eh?

I did a search and found a malware sample described here that exhibits this behavior, and I found another description here.  Hopefully, that might provide some sort of idea as to how pervasive this artifact is.

@DanielleEveIR had another interesting tweet, stating that if your app makes a copy of itself and then launches the copy, it might be malware.  Okay, she's starting to sound like the Jeff Foxworthy of IR..."you might be malware if..."...but she has a very good point.  Our team recently saw the LaZagne credential theft tool being run in an infrastructure, and if you've ever seen or tested this, that's exactly what it does.  This would make a good watchlist item, as well...regardless of what the application name is, if the process name is the same as the parent process name, flag that puppy!  You can also include this in any script that you use that parses Security Event Logs (for event ID 4688) or Sysmon Event Logs.

Defender Bias
There've been a number of blog posts that have discussed analyst bias when it comes to DFIR, threat intel, and attribution.

Something that I haven't seen discussed much is blue team or defender bias.  Wait...what?  What is "defender bias"?  Let's look at some examples...you're sitting in a meeting, discussing an incident that your team is investigating, and you're fully aware that you don't have all the data at this point.  You're looking at a few indicators, maybe some files and Windows Event Log records, and then someone says, "...if I were the bad guy, I'd...".  Ever have that happen?  Being an incident responder for about 17 years, I've heard that phrase spoken.  A lot.  Sometimes by members of my team, sometimes by members of the client's team.

Another place that defender bias can be seen is when discussing "crown jewels".  One of the recommended exercises while developing a CSIRP is to determine where the critical data for the organization is located within the infrastructure, and then develop response plans around that data. The idea of this exercise is to accept that breaches are inevitable, and collapse the perimeter around the critical data that the organization relies on to function.

But what happens when you don't have the instrumentation and visibility to determine what the bad guy is actually doing?  You'll likely focus on protected that critical data while the bad guy is siphoning off what they came for.

The point is that what may be critical to you, to your business, may not be the "crown jewels" from the perspective of the adversary.  Going back as far as we can remember, reports from various consulting organizations have referred to the adversary as having a "shopping list", and while your organization may be on that list, the real question isn't just, "..where are your critical assets?", it's also "...what is the adversary actually doing?"

What if your "crown jewels" aren't what the adversary is after, and your infrastructure is a conduit to someone else's infrastructure?  What if your "crown jewels" are the latest and greatest tech that your company has on the drawing boards, and the adversary is instead after the older gen stuff, the tech shown to work and with a documented history and track record of reliability?   Or, what if your "crown jewels" are legal positions for clients, and the adversary is after your escrow account?

My point is that there is going to be a certain amount of defender bias in play, but it's critical for organizations to have situational awareness, and to also realize when there are gaps in that situational awareness.  What you decide are the "crown jewels", in complete isolation from any other input, may not be what the adversary is after.  You'll find yourself hunkered down in your Maginot Line bunkers, awaiting that final assault, only to be mystified when it never seems to come.

1 comment:

Anonymous said...

Regarding this snippet: "... if the process name is the same as the parent process name, flag that puppy!" it seems that this is not an absolute indicator, correct?

Maybe I'm doing the wrong search, but I've been playing around with that simple logic and it seems that when I've reviewed EventID 4688 there are several instances of exe's where the creator process name is the same as the new process name.

For example: I have seen multiple instances of iexplore launching iexplore.exe and of chrome launching chrome.exe

So it would seem that this type of indicator would need to be used in conjunction with other indicators to determine if something malicious was occurring on the device....

Am I understanding that correctly?