Links

Data Exfil
A question that analysts get from time to time is "was any data exfiltrated from this system?"  Sometimes, this can be easy to determine; for example, if the compromised system had a web server running (and was accessible from the Interwebs), you might find indications of GET requests for unusual files in the web server logs.  You would usually expect to find something like this if the bad guy archived whatever they'd collected, moved the archive(s) into a web folder, and then issued a GET request to download the archive to their local system.  In many cases, the bad guy has then deleted the archive.  With no instrumentation on the system, the only place you will find any indication of this activity is in the web server logs.

However, for the most part, definitive determination of data exfiltration is almost impossible without the appropriate instrumentation; either having a packet sniffer on the wire at the time of the transfer, or appropriate endpoint agent monitoring process creation events (see the Endpoints section below) in order to catch/record command lines.  In the case of endpoint monitoring, you'd likely see the use of an archiving tool, and little else until you moved to the web server logs (given the above example).

Another area to look is the Background Intelligent Transfer Service, or "BITS".  SecureWorks has a very interesting blog post that illustrates one way that this native Windows service has been abused.  I highly suggest that if you're doing any kind of DFIR or threat hunting work, you do a good, solid read of the SecureWorks blog post.

I am not aware of any publicly-available tools for parsing the BITS qmgr0.dat or qmgr1.dat files, but you can use 'strings' to locate information of interest, and then use a hex editor from that point in order to get more specific information about the type of transfer (upload, download) that may have taken place, and it's status.  Also, be sure to keep an eye on those Windows Event Logs, as well.

Finding Bad
Jack Crook recently started a new blog, Finding Bad, covering DFIR and threat hunting topics.  As

Jack's most recent post on hunting for lateral movement is a good start, but IMHO, the difference in artifacts on the source vs the destination system during lateral movement needs to be clearly delineated.  Yeah, I know...it may be pedantic, but from my perspective, there is actually a pretty huge difference, and that difference needs to be understood, for no other reason that because the artifacts on each system are different.

Endpoints
Adam recently posted a spreadsheet of various endpoint solutions that are available...it's interesting to see the comparison.  Having detailed knowledge of one of the listed solutions does a level set with respect to my expectations regarding the others.

MAC Addresses in the Registry
I recently received a question from a friend regarding MAC addresses being stored in the Registry.  It turns out, there are places where the MAC address of a system is "stored" in the Registry, just not in the way you might think.  For example, running the mountdev2.pl RegRipper plugin, we see (at the bottom of the output) something like this:

Unique MAC Addresses:
80:6E:6F:6E:69:63

I should also point out that the macaddr.pl plugin, which is about 8 yrs old at this point, also might provide some information.

Registry Findings - 2012
The MAC Daddy - circa 2007

EventMonkey
I ran across EventMonkey (wiki here) recently, which is a Python-based event processing utility.  What does that mean?  Well, from the wiki, that means "A multiprocessing utility that processes Windows event logs and stores into SQLite database with an option to send records to Elastic for indexing."  Cool.

This definitely seems like an interesting tool for DFIR analysts.  Something else that the tool reportedly does is process the JSON output from Willi's EVTXtract.

Presentations
As I've mentioned before, later this month I'll be presenting at ArchC0N, discussing some of the misconceptions of ransomware.  I ran across an interesting blog post recently regarding, Fixing the Culture of Infosec Presentations.  I can't say that I fully agree with the concept behind the post, nor with the contents of blog post.  IMHO, the identified "culture" is from too narrow a sample of conferences...it's unclear as to which "infosec conferences" this discussion applies.

I will say this...I stopped attending some conferences a while back because of the nature of how they were populated with speakers.  Big-named, headliner speakers were simply given a time slot, and in some cases, did not even prepare a talk.  I remember one such speaker using their time slot to talk about wicca.

At one point in the blog post, the author refers to a particular presenter who simply reads an essay that they've written; the author goes on to say that they prefer that.  What's the point?  If you write an essay, and it's available online, why spend your time reading it to the audience, when the audience is (or should be) fully capable of reading it themselves?

There's another statement made in the blog post that I wanted to comment on...

We have a force field up that only allows like .1% of our community to get on the stage, and that’s hurting all of us. It’s hurting the people who are too afraid to present. It’s hurting the conference attendees. And it’s hurting the conferences themselves because they’re only seeing a fraction of the great content that’s out there.

I completely agree that we're missing a lot of great content, but I do not agree that "we have put up a force field"; or, perhaps the way to look at it is that the force field is self-inflicted.  I have seen some really good presentations out there, and the one thing that they all have in common is that the speaker is comfortable with public speaking.  I say "self-inflicted" because there are also a lot of people in this field who are not only afraid to create a presentation and speak, they're also afraid to ask questions, or offer their own opinion on a topic.

What I've tried to do when presenting is to interact with the audience, to solicit their input and engage them.  After all, being the speaker doesn't mean that I know everything...I can't possibly know or have seen as much as all of us put together.  Rather than assume the preconceptions of the audience, why not ask them?  Admittedly, I will sometimes ask a question, and the only sound in the room is me breathing into the mic...but after a few minutes folks tend to start loosing up a bit, and in many cases,  a pretty good interactive discussion ensues.  In the end, we all walk away with something.

I also do not believe that "infosec presentations" need to be limited to the rather narrow spectrum described in the blog post.  Attack, defend, or a tool for doing either one.  There is so much more than that out there and available.  How about something new that you've seen (okay, maybe that would part of "defend"), or a new way of looking at something you've seen?  Want a good example?  Take a look at Kevin Strickland's blog post on the Evolution of the Samas Ransomware.  At the point where he wrote that blog post, SecureWorks (full disclosure, Kevin and I are both employed by SecureWorks) had seen several Samas ransomware cases; Kevin chose to look at what we'd all seen from a different perspective.

There are conferences that have already gone to taking at least some of the advice in the blog post. For example, the last time I attended a SANS360 presentation, there were 10 speakers, each with 6 minutes to present.  Some timed their presentations down to the second, while others seemed to completely ignore the 6 minute limit on presentations.  Even so, it was great to see a speaker literally remove all of the fluff and focus on one specific topic, and get that across.