RegRipper
Not all RegRipper plugins come from external sources; in fact, a good number of the plugins I've written start as something I've run across on the Internet, from various sources (most times Twitter). Sometimes it's a blog post, other times it's a malware write-up, or it could be the result of a working a forensic challenge.
Based on Adam's post, I created a plugin (named wsh_settings.pl) that outputs the values of the Settings key, and includes an Analysis Tip that references the Remote value.
I also updated the clsid.pl plugin to incorporate looking for the TreatAs value. On a sample hive that I have from a Win7 SP1 system, I ran the following command:
rip -r d:\cases\test\software -p clsid | find "TreatAs"
I got a total of 9 hits, 7 of which were all for the same GUID (i.e., {F20DA720-C02F-11CE-927B-0800095AE340}), which appears to refer to packager.dll.
I also created a TLN output version of clsid.pl (named clsid_tln.pl) so that this information can be used to create timeline (in and of itself), or can be added to a timeline that incorporates other data sources. I know from initial testing that under "normal" circumstances, the LastWrite times for the keys may be lumped together around the same time, but what we're looking for here is outliers, timeline entries that correspond with other suspicious activity, forming an artifact cluster.
Book
I received an email from my publisher on 20 Aug 2018 telling me that Investigating Windows Systems had officially been published, and is available here through the publisher! I'm not sure what that means with respect to the book actually being available or shipped (if you pre-ordered it) from Amazon; for me, it's a milestone, something I can mark off my list. That's #9 down (as in, nine books that I've authored), and I'm currently working on Practical Windows Investigations, which will is due out next year.
IWS is a bit of a departure from my previous books; instead of listing various artifacts that you could use in an investigation, and leaving it to the reader to figure out how to string them together, I used images available online to illustrate what an investigation might look like. Using the images, I provide analysis goals that are more inline with what one might expect to see during a real world IR investigation. I then walk through the analysis of the image (based on the stated goals), providing decision pivot points along the way. However, these investigations are somewhat naturally limited...they aren't enterprise level, don't involve things like lateral movement, etc. As such, these things aren't addressed, but I did try to cover as much as I could with what was available.
I have a GitHub repo for the book - it doesn't contain a great deal at the moment, just links to the images used, and in the folder for chapter 4, code that I wrote for that particular chapter. I'm sure I'll be adding material over time, either based on requests or based on interesting things from my notes and folders for the book.
Practical Windows Investigations is going to swing the pendulum back a bit, so to speak, in that rather than just looking at artifacts, I'm focusing on different aspects of investigations and addressing what can be achieved when pursuing those avenues. The book is currently spec'd at 12 chapters, and the list is not too different from what was listed in this post from March.
The current chapters are:
Core Concepts
How to analyze Windows Event Logs
How to get the most out of RegRipper
Malware Detection
How to determine data exfiltration
File (LNK, DOCX/DOC, PDF) Analysis
How to investigate lateral movement
How to investigate program execution
How to investigate user activity
How to correlate/associate a device with a user (USB, Bluetooth)
How to detect/analyze the use of anti-forensics
Making use of VSCs
As with my previous books, tools used for analysis will be free and open source tools; this is due to the fact that I simply do not have access to commercial tools. This is a topic that is continually brought up during prospectus reviews, and the reviewers simply do not seem to understand.
Wednesday, August 22, 2018
Saturday, August 18, 2018
Updates
Win10 Notification Database
Leave it to MS to make our jobs as DFIR analysts fun, all day, every day! Actually, that is one of the things I've always found fascinating about analyzing Windows systems is that the version of Windows, more often than not, will predicate how far you're able to go with your analysis.
An interesting artifact that's available on Win10 systems is the notification database, which is where those pop up messages you receive on the desktop are stored. Over the past couple of months, I've noticed that on my work computer, I get more of these messages, because it now ties into Outlook. It turns out that this database is a SQLite database. Lots of folks in the community use various means to parse SQLite databases; one of the popular ways to do this is via Python, and subsequently, you can often find either samples via tutorials, or full-on scripts to parse these databases for you.
MalwareMaloney posted a very interesting article on parsing the write-ahead logging (.wal) file for the database. Also, as David pointed out,
Anytime you're working with a SQLite database, you should consider taking a look at Mari's blog post on recovering deleted data.
RegRipper
Based on input from a user, I updated the sizes.pl plugin in a way that you may find useful; it now displays a brief sample of the data 'found' by the plugin (default is 48 bytes/characters). So, instead of just finding a value of a certain size (or above) and telling you that it found it, the plugin now displays a portion of the data itself. The method of display is based on the data type...if it's a string, it outputs a portion of the string, and if the data is binary, it outputs of hex dump of the pre-determined length. That length, as well as the minimum data size, can be modified by opening the plugin in Notepad (or any other editor) and modifying the "$output_size" and "$min_size" values, respectively.
Here is some sample output from the plugin, run against a Software hive known to contain a malicious Powershell script:
sizes v.20180817
(All) Scans a hive file looking for binary value data of a min size (5000)
Key : \4MX64uqR Value: Dp8m09KD Size: 7056 bytes
Data Sample (first 48 bytes) : aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAA...
From here, I'd definitely pivot on the key name ("4MX64uqR"), looking into a timeline, as well as searching other locations in the Registry (auto start locations??) and file system for references to the name.
Interestingly enough, while working on updating this plugin, I referred back to pg 34 of Windows Registry Forensics and for the table of value types. Good thing I keep my copy handy for just this sort of emergency. ;-)
Mari has an excellent example of how she has used this plugin in actual analysis here.
IWS
Speaking of books, Investigating Windows Systems is due out soon. I'm really looking forward to this one, as it's a different approach all together from my previous books. Rather than listing the various artifacts that are available on Windows systems, folks like Phill Moore, David Cowen and Ali Al-Shemery graciously allowed me access to the images that they put together so that I could work through them. The purpose of the book is to illustrate a way of stringing the various artifacts together in to a full-blown investigation, with analysis decisions called out and discussed along the way.
What I wanted to do with the book is present something more of a "real world" analysis approach. Some of the images came with 30 or more questions that had to be answered as part of the challenge, and in my limited experience, that seemed a bit much.
The Github repo for the book has links to the images used, and for one chapter, has the code I used to complete a task. Over time, I may add other bits and pieces of information, as well.
OSDFCon
My submission for OSDFCon was accepted, so I'll be at the conference to talk about RegRipper, and how you can really get the most out of it.
Here is the list of speakers at the conference...I'm thinking that my speaker bio had something to do with me being selected. ;-)
Leave it to MS to make our jobs as DFIR analysts fun, all day, every day! Actually, that is one of the things I've always found fascinating about analyzing Windows systems is that the version of Windows, more often than not, will predicate how far you're able to go with your analysis.
An interesting artifact that's available on Win10 systems is the notification database, which is where those pop up messages you receive on the desktop are stored. Over the past couple of months, I've noticed that on my work computer, I get more of these messages, because it now ties into Outlook. It turns out that this database is a SQLite database. Lots of folks in the community use various means to parse SQLite databases; one of the popular ways to do this is via Python, and subsequently, you can often find either samples via tutorials, or full-on scripts to parse these databases for you.
MalwareMaloney posted a very interesting article on parsing the write-ahead logging (.wal) file for the database. Also, as David pointed out,
Anytime you're working with a SQLite database, you should consider taking a look at Mari's blog post on recovering deleted data.
RegRipper
Based on input from a user, I updated the sizes.pl plugin in a way that you may find useful; it now displays a brief sample of the data 'found' by the plugin (default is 48 bytes/characters). So, instead of just finding a value of a certain size (or above) and telling you that it found it, the plugin now displays a portion of the data itself. The method of display is based on the data type...if it's a string, it outputs a portion of the string, and if the data is binary, it outputs of hex dump of the pre-determined length. That length, as well as the minimum data size, can be modified by opening the plugin in Notepad (or any other editor) and modifying the "$output_size" and "$min_size" values, respectively.
Here is some sample output from the plugin, run against a Software hive known to contain a malicious Powershell script:
sizes v.20180817
(All) Scans a hive file looking for binary value data of a min size (5000)
Key : \4MX64uqR Value: Dp8m09KD Size: 7056 bytes
Data Sample (first 48 bytes) : aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAA...
From here, I'd definitely pivot on the key name ("4MX64uqR"), looking into a timeline, as well as searching other locations in the Registry (auto start locations??) and file system for references to the name.
Interestingly enough, while working on updating this plugin, I referred back to pg 34 of Windows Registry Forensics and for the table of value types. Good thing I keep my copy handy for just this sort of emergency. ;-)
Mari has an excellent example of how she has used this plugin in actual analysis here.
IWS
Speaking of books, Investigating Windows Systems is due out soon. I'm really looking forward to this one, as it's a different approach all together from my previous books. Rather than listing the various artifacts that are available on Windows systems, folks like Phill Moore, David Cowen and Ali Al-Shemery graciously allowed me access to the images that they put together so that I could work through them. The purpose of the book is to illustrate a way of stringing the various artifacts together in to a full-blown investigation, with analysis decisions called out and discussed along the way.
What I wanted to do with the book is present something more of a "real world" analysis approach. Some of the images came with 30 or more questions that had to be answered as part of the challenge, and in my limited experience, that seemed a bit much.
The Github repo for the book has links to the images used, and for one chapter, has the code I used to complete a task. Over time, I may add other bits and pieces of information, as well.
OSDFCon
My submission for OSDFCon was accepted, so I'll be at the conference to talk about RegRipper, and how you can really get the most out of it.
Here is the list of speakers at the conference...I'm thinking that my speaker bio had something to do with me being selected. ;-)
Friday, August 10, 2018
Gaps and Up-Hill Battles
I've been thinking about writing a RegRipper plugin that looks for settings that indicate certain functionality in Windows has been disabled, such as maintaining JumpLists, as well as MRUs in the Registry.
Hold on for a segue...
David Cowen recently requested input via his blog, regarding the use of anti-forensics tools seen in the wild. A little more than two years ago, Kevin S. wrote this really awesome blog post regarding the evolution of the Samas/Samsam ransomware, and I know you're going to ask, "great, but what does this have to do with anti-forensics tools?" Well, about half way down the post, you'll see where Kevin mentions that one of the early variants of Samas included a copy of sdelete in one of its resource sections.
As usual, Brett made some very poignant comments, in this case regarding seeing anti- or counter-forensics tools in the wild; specifically, just having the program on a system doesn't mean it was used, and with limited visibility, it's difficult to see how it was used.
Now, coming back around...
What constitutes counter-forensics efforts, particularly when it comes to user intent? Do we really know the difference between user intent and operating system/application functionality? Maybe more importantly, do we know that there is such a thing?
I've seen too many times where leaps (assumptions, speculation) have been made without first fully examining the available data, or even just looking a little bit closer. Back in the days of XP, an issue I ran into was an empty Recycle Bin for a user, which might have been a bad thing, particularly following a legal hold. So, an analyst would preview an image, find an empty Recycle Bin, and assume that the user had emptied it, following the legal hold announcement. But wait...what was the NukeOnDelete setting? Wait...the what? Yes, with this functionality enabled, the user would delete a file as they normally would, but the file would not appear in the Recycle Bin.
Other functionality that's similar to this includes, did the user clear the IE history, or was it the result of the regularly scheduled purge? Did the user delete files and run defrag after a legal hold order, or was defrag run automatically by the OS?
Skipping ahead to modern times, what happens if you get a "violation of acceptable use policies" case, or a harassment case, or any other case where user activity is a (or the) central focus of your examination, and the user has no JumpLists. Yes, the automatic JumpLists folder is empty. Does that seem possible? Or did the user suspect someone would be looking at their system, and purposely delete them? Well, did you check if the tracking of JumpLists had been disabled via the Registry?
My point is that there is functionality within Windows to disable the recording and maintenance of various artifacts that analysts use to do their jobs. This functionality can be enabled or disabled through the Registry. As such, if an analyst does not find what they expect to find (i.e., files in the Recycle Bin, RecentDocs populated, etc.) then it's a good idea to check for the settings.
Oh, and yes, I did write the plugin, the current iteration of which is called disablemru.pl. I'll keep adding to it as more information becomes available.
Hold on for a segue...
David Cowen recently requested input via his blog, regarding the use of anti-forensics tools seen in the wild. A little more than two years ago, Kevin S. wrote this really awesome blog post regarding the evolution of the Samas/Samsam ransomware, and I know you're going to ask, "great, but what does this have to do with anti-forensics tools?" Well, about half way down the post, you'll see where Kevin mentions that one of the early variants of Samas included a copy of sdelete in one of its resource sections.
As usual, Brett made some very poignant comments, in this case regarding seeing anti- or counter-forensics tools in the wild; specifically, just having the program on a system doesn't mean it was used, and with limited visibility, it's difficult to see how it was used.
Now, coming back around...
What constitutes counter-forensics efforts, particularly when it comes to user intent? Do we really know the difference between user intent and operating system/application functionality? Maybe more importantly, do we know that there is such a thing?
I've seen too many times where leaps (assumptions, speculation) have been made without first fully examining the available data, or even just looking a little bit closer. Back in the days of XP, an issue I ran into was an empty Recycle Bin for a user, which might have been a bad thing, particularly following a legal hold. So, an analyst would preview an image, find an empty Recycle Bin, and assume that the user had emptied it, following the legal hold announcement. But wait...what was the NukeOnDelete setting? Wait...the what? Yes, with this functionality enabled, the user would delete a file as they normally would, but the file would not appear in the Recycle Bin.
Other functionality that's similar to this includes, did the user clear the IE history, or was it the result of the regularly scheduled purge? Did the user delete files and run defrag after a legal hold order, or was defrag run automatically by the OS?
Skipping ahead to modern times, what happens if you get a "violation of acceptable use policies" case, or a harassment case, or any other case where user activity is a (or the) central focus of your examination, and the user has no JumpLists. Yes, the automatic JumpLists folder is empty. Does that seem possible? Or did the user suspect someone would be looking at their system, and purposely delete them? Well, did you check if the tracking of JumpLists had been disabled via the Registry?
My point is that there is functionality within Windows to disable the recording and maintenance of various artifacts that analysts use to do their jobs. This functionality can be enabled or disabled through the Registry. As such, if an analyst does not find what they expect to find (i.e., files in the Recycle Bin, RecentDocs populated, etc.) then it's a good idea to check for the settings.
Oh, and yes, I did write the plugin, the current iteration of which is called disablemru.pl. I'll keep adding to it as more information becomes available.
Friday, August 03, 2018
The Future of IR, pt I
I've been doing IR work for a while now, and I've had the great fortune of watching things grow over time.
When I started in the industry, there were no real training courses or programs available, and IR business models pretty much required (and still do) that a new analyst is out on the road as soon as they're hired. I got started in the industry and developed some skills, had some training (initial EnCase training in '99), and when I got to a consulting position, I was extremely fortunate to have a boss who took an interest in mentoring me and providing guidance, which I greatly appreciate to this day.
However, I've seen this same issue with business models as recently as 2018. New candidates for IR teams are interviewed, and once they're hired and go through the corporate on-boarding, there is little if any facility for training or supervising...the analysts are left to themselves. Yes, they are provided with tools, software products, and report templates, but for the most part, that's it. How are they communicating with clients? Are they sending in regular updates? If so, are those updates appropriate, and more importantly, are they technically correct? Are the analysts maintaining case notes?
Over the years of doing IR work, I ran into the usual issues that most of us see...like trying to find physical systems in a data center by accessing the system remotely and opening the CD-ROM tray. But two things kept popping into my mind; one was, I really wished that there was a way to get a broader view of what was happening during an incident. Rather than the client sending me the systems that they thought were involved or the "key" systems, what if I could get a wider view of the incident? This was very evident when there were indications on the systems I was examining that pointed to them being accessed from other systems, or accessing other systems, on the same infrastructure.
The other was that I was spending a lot of time looking at what was left behind after a process ran. I hadn't seen BigFoot tromp across the field, because due to the nature of IR, all I had to look at were footprints that were several days old. What if, instead of telling the client that there were gaps in the data available for analysis (because I'm not going to guess or speculate...) I actually had a recording of the process command lines?
During one particularly fascinating engagement, it turned out that the client had installed a monitoring program on two of the affected systems. The program was one of those applications that parents use to monitor their kid's computers, and what the client provided was 3-frame-per-second videos of what went on. As such, I just accessed the folder, found all of the frames with command prompts open, and could see exactly what the adversary typed in at the prompt. I then went back and watched the videos to see what the adversary was doing via the browser, as well as via other GUI applications.
How useful are process command lines? Right now, there're considerable artifacts on systems that give analysts a view into what programs were run on a system, but not how they were run. For instance, during an engagement where we had established process creation monitoring across the enterprise, an alert was triggered on the use of rar.exe, which is very often as a means of staging files for exfiltration. The alert was not for "rar.exe", as the file had been renamed, but was instead for command line options that had been used, and as such, we had the password used to encrypt the archives. When we receive the image from the system and recovered the archives (they'd been deleted after exfil), we were able to open the archives and show the client exactly what was taken.
So, things have progressed quite a bit over the years, while some things remain the same. While there have been significant in-roads made into establishing enterprise-wide visibility, the increase of device types (Windows, Mac, Linux, IoT, mobile, etc.) still requires us to have the ability to go out and get (or receive) individual devices or systems for collection and analysis; those skills will always be required. As such, if the business model isn't changed in some meaningful way, we are going to continue to have instances where someone without the appropriate skill sets is sent out on their own.
The next step in the evolution of IR is MDR, which does more than just mash MSS and IR together. What I mean by that is that the typical MSS functionality receives an alert, enriches it somehow, and sends the client a ticket (email, text, etc.). This then requires that the client receive and understand the message, and figure out how they need to respond...or that they call someone to get them to respond. While this is happening, the adversary is embedding themselves deeply within the infrastructure...in the words of Jesse Ventura from the original Predator movie, "...like an Alabama tick."
Okay, so what do you do? Well, if you're going to have enterprise-wide visibility, how about adding enterprise-wide response and remediation? If we're able to monitor process command lines, what if we could specify conditions that are known pretty universally to be "bad", and stop the processes? For example, every day, hundreds of thousands of us log into our computers, open Outlook, check our email, and read attachments. This is all normal. What isn't normal is when that Word document that arrived as an email attachment "opens" a command prompt and downloads a file to the system (as a result of an embedded macro). If it isn't normal and it isn't supposed to happen and we know it's bad, why not automatically block it? Why not respond at software speeds, rather than waiting for the detection to get back to the SOC, for an analyst to review it, for the analyst to send a ticket, and for the client to receive the ticket, then open it, read it, and figure out what to do about it? In that time, your infrastructure could be hit by a dedicated adversary, or by ransomware.
If you stop the download from occurring, you prevent all sorts of bad follow-on things from happening, like having to report a "personal data breach", per GDPR.
Of course, the next step would be to automatically isolate the system on the network. Yes, I completely understand that if someone's trying to do work and they can't communicate off of their own system, it's going to hamper or even obviate their workflow. But if that were the case, why did they say, "Yes, I think I will "enable content", thank you very much!", after the phishing training showed them why they shouldn't do that? I get that it's a pain in the hind end, but which is worse...enterprise-wide ransomware that not only shuts everything down but requires you to report to GDPR, or one person having to have a new computer to get work done?
So, the overall point I'm trying to make here is that the future of IR is going to be to detect and respond faster. Faster than we have been. Get ahead of the adversary, get inside their OODA loop, and cycle through the decision process faster than they can respond. I've seen this in action...the military has things called "immediate actions", which are actions that, when a condition is met, you respond immediately. In the military, you train at these things until they're automatic muscle memory, so that when those things go occur (say, your rifle jams), you perform the actions immediately. We can apply these sorts of things to the OODA loop by removing the need to make decisions under duress because we made them ahead of time; we made the decision regarding a specific action while we had the time to think about it, so that we didn't have to try to make the decision during an incident.
In order to detect and respond quicker, this is going to require a couple of things:
- Visibility
- Intelligence
- Planning
I'll be addressing these topics in future blog posts.
When I started in the industry, there were no real training courses or programs available, and IR business models pretty much required (and still do) that a new analyst is out on the road as soon as they're hired. I got started in the industry and developed some skills, had some training (initial EnCase training in '99), and when I got to a consulting position, I was extremely fortunate to have a boss who took an interest in mentoring me and providing guidance, which I greatly appreciate to this day.
However, I've seen this same issue with business models as recently as 2018. New candidates for IR teams are interviewed, and once they're hired and go through the corporate on-boarding, there is little if any facility for training or supervising...the analysts are left to themselves. Yes, they are provided with tools, software products, and report templates, but for the most part, that's it. How are they communicating with clients? Are they sending in regular updates? If so, are those updates appropriate, and more importantly, are they technically correct? Are the analysts maintaining case notes?
Over the years of doing IR work, I ran into the usual issues that most of us see...like trying to find physical systems in a data center by accessing the system remotely and opening the CD-ROM tray. But two things kept popping into my mind; one was, I really wished that there was a way to get a broader view of what was happening during an incident. Rather than the client sending me the systems that they thought were involved or the "key" systems, what if I could get a wider view of the incident? This was very evident when there were indications on the systems I was examining that pointed to them being accessed from other systems, or accessing other systems, on the same infrastructure.
The other was that I was spending a lot of time looking at what was left behind after a process ran. I hadn't seen BigFoot tromp across the field, because due to the nature of IR, all I had to look at were footprints that were several days old. What if, instead of telling the client that there were gaps in the data available for analysis (because I'm not going to guess or speculate...) I actually had a recording of the process command lines?
During one particularly fascinating engagement, it turned out that the client had installed a monitoring program on two of the affected systems. The program was one of those applications that parents use to monitor their kid's computers, and what the client provided was 3-frame-per-second videos of what went on. As such, I just accessed the folder, found all of the frames with command prompts open, and could see exactly what the adversary typed in at the prompt. I then went back and watched the videos to see what the adversary was doing via the browser, as well as via other GUI applications.
How useful are process command lines? Right now, there're considerable artifacts on systems that give analysts a view into what programs were run on a system, but not how they were run. For instance, during an engagement where we had established process creation monitoring across the enterprise, an alert was triggered on the use of rar.exe, which is very often as a means of staging files for exfiltration. The alert was not for "rar.exe", as the file had been renamed, but was instead for command line options that had been used, and as such, we had the password used to encrypt the archives. When we receive the image from the system and recovered the archives (they'd been deleted after exfil), we were able to open the archives and show the client exactly what was taken.
So, things have progressed quite a bit over the years, while some things remain the same. While there have been significant in-roads made into establishing enterprise-wide visibility, the increase of device types (Windows, Mac, Linux, IoT, mobile, etc.) still requires us to have the ability to go out and get (or receive) individual devices or systems for collection and analysis; those skills will always be required. As such, if the business model isn't changed in some meaningful way, we are going to continue to have instances where someone without the appropriate skill sets is sent out on their own.
The next step in the evolution of IR is MDR, which does more than just mash MSS and IR together. What I mean by that is that the typical MSS functionality receives an alert, enriches it somehow, and sends the client a ticket (email, text, etc.). This then requires that the client receive and understand the message, and figure out how they need to respond...or that they call someone to get them to respond. While this is happening, the adversary is embedding themselves deeply within the infrastructure...in the words of Jesse Ventura from the original Predator movie, "...like an Alabama tick."
Okay, so what do you do? Well, if you're going to have enterprise-wide visibility, how about adding enterprise-wide response and remediation? If we're able to monitor process command lines, what if we could specify conditions that are known pretty universally to be "bad", and stop the processes? For example, every day, hundreds of thousands of us log into our computers, open Outlook, check our email, and read attachments. This is all normal. What isn't normal is when that Word document that arrived as an email attachment "opens" a command prompt and downloads a file to the system (as a result of an embedded macro). If it isn't normal and it isn't supposed to happen and we know it's bad, why not automatically block it? Why not respond at software speeds, rather than waiting for the detection to get back to the SOC, for an analyst to review it, for the analyst to send a ticket, and for the client to receive the ticket, then open it, read it, and figure out what to do about it? In that time, your infrastructure could be hit by a dedicated adversary, or by ransomware.
If you stop the download from occurring, you prevent all sorts of bad follow-on things from happening, like having to report a "personal data breach", per GDPR.
Of course, the next step would be to automatically isolate the system on the network. Yes, I completely understand that if someone's trying to do work and they can't communicate off of their own system, it's going to hamper or even obviate their workflow. But if that were the case, why did they say, "Yes, I think I will "enable content", thank you very much!", after the phishing training showed them why they shouldn't do that? I get that it's a pain in the hind end, but which is worse...enterprise-wide ransomware that not only shuts everything down but requires you to report to GDPR, or one person having to have a new computer to get work done?
So, the overall point I'm trying to make here is that the future of IR is going to be to detect and respond faster. Faster than we have been. Get ahead of the adversary, get inside their OODA loop, and cycle through the decision process faster than they can respond. I've seen this in action...the military has things called "immediate actions", which are actions that, when a condition is met, you respond immediately. In the military, you train at these things until they're automatic muscle memory, so that when those things go occur (say, your rifle jams), you perform the actions immediately. We can apply these sorts of things to the OODA loop by removing the need to make decisions under duress because we made them ahead of time; we made the decision regarding a specific action while we had the time to think about it, so that we didn't have to try to make the decision during an incident.
In order to detect and respond quicker, this is going to require a couple of things:
- Visibility
- Intelligence
- Planning
I'll be addressing these topics in future blog posts.
Notes, etc.
Case Notes
@mattnotmax recently posted a blog on "contemporaneous notes".
But wait...there's more.
I agree with what Matt said regarding notes. 1000%.
I've been on engagements where things have gone sideways. In one instance, I was assigned by the PoC to work with a network engineer to get access to network device logs. We walked through a high-level network diagram on a white board, and at every point, I was told by the network engineer that there were no logs available from that device, nor that one, and definitely not that one. I took a picture with my cell phone of the white board to document my "findings" in that regard, and when I met with the PoC the following morning, he seemed bothered by the fact that I hadn't gotten anywhere the previous day. He called in the network engineer, who then said that he'd never said that logs were not available. I pulled up the photo of the white board on my laptop and walked through it. By the time we got to the end of the engagement, I never did get any logs from any of the network devices. However, I had documented my findings (written, as well as with the photo) and had a defensible position, not just for myself, but also for my boss to take up the chain, if the issue ended up going that far.
As a side note, I make it a practice that if I get the sense that something is fishy, or that an engagement could go sideways, I'll call my boss and inform my management chain first, so that they hear it from me. Better that, than the first they hear of any issue is an angry call from a client. This is where notes really help...IR engagements are highly stressful events for everyone involved, and having notes is going to help you when it comes to who said/did what, and when.
Rules
One of the questions Matt addresses in his blog post is the 'rules' of the notes; whenever I've been asked about this, the question has always been, "what's the standard?" My response has always been pretty simple...reproduceability. You need to write your notes to the point that 6 months or a year later, you (or more importantly, someone else) can take the notes and the data, and reproduce the results.
Standards
In fact, I have been asked the question about the "standard" so much over the years that it's become a high-fidelity indicator that notes will not be taken. So far, every single time I've been asked about the "standard" to which notes should be taken, note have not been kept.
When I started with ISS in 2006, I was provided dongles for AccessData FTK, as well as for EnCase 4.22 and 6.19. When I performed work, I noted which application I used right along with what I did...because that was important. When we (our team) determined that one of the built-in functions for a commercial tool was not, in fact, finding all valid credit card numbers (kind of important for PFI work...), we worked with Lance Mueller to get our own function working, and made the use of the result script part of our standard operating (and repeatable) procedure.
Part of the PFI work at the time also included a search for hashes, file names, and a few other indicators. Our notes had to have the date of the work, and our SOP required that just prior to running the searches for those indicators that we pull down the latest-and-greatest copies of the indicator lists.
Why was this important? Well, if someone found something in the data (or on the original system) six or eight months later, we had clear and concise documentation as to what steps were taken when. That way, if the analyst was on leave or on another engagement, a team lead or the director could easily answer the questions. With some simple, clear, and concise notes, the team lead could say, "Yes, but that case was worked 8 months ago, and that indicator was only made available as part of last month's list." Boom. Done. Next.
Application
Another question that comes up is, what application should I use? Well, I started with Notepad, because it was there. I loved it. When I received a laptop from a client and had to remove the hard drive for imaging, I could paste a link to the online instructions I followed, and I could download the instructions and keep them in a separate file, or print them out and keep them in a folder. URL link or printed out, I had an "appendix" to my notes. When I got to the point where I wanted to add photos to my notes, I simply used Write or Word. Depending upon your requirements, you may not need anything schmancy or "high speed, low drag"...just what you've got available may work just fine.
If you're looking for something a little more refined when it comes to keeping notes, take a look at ForensicNotes.
Conclusion
Many of us say/talk about it...we keep notes because at some point in the future, someone's going to have questions. I was in a role where we said that repeatedly...and then it happened. Fully a year after working an engagement, questions came up. Serious questions. Through corporate counsel. And guess what...there were no notes. No one had any clue as to what happened, and by "no one", I'm only referring to those who actually worked the case. Look, we say these things not because we're being silly or we're bored or we just want to be mean...we say them because they're significant, serious, and some of us have seen the damage that can occur to reputation of a company or an individual when notes aren't maintained.
Even with all of this being said, and even with Matt's blog post, there is no doubt in my mind that many DFIR folks are going to continue to say, "I don't want my notes to be discoverable, because a defense attorney would tear them/me apart on the stand." According to Brett Shavers, that's going to happen anyway, with or without notes, so better to have the notes and be able to answer questions with confidence, or at least something more than, "I don't know". The simple fact is that if you're not keeping case notes, you're doing yourself, your fellow analysts, and your client all a huge disservice.
@mattnotmax recently posted a blog on "contemporaneous notes".
But wait...there's more.
I agree with what Matt said regarding notes. 1000%.
I've been on engagements where things have gone sideways. In one instance, I was assigned by the PoC to work with a network engineer to get access to network device logs. We walked through a high-level network diagram on a white board, and at every point, I was told by the network engineer that there were no logs available from that device, nor that one, and definitely not that one. I took a picture with my cell phone of the white board to document my "findings" in that regard, and when I met with the PoC the following morning, he seemed bothered by the fact that I hadn't gotten anywhere the previous day. He called in the network engineer, who then said that he'd never said that logs were not available. I pulled up the photo of the white board on my laptop and walked through it. By the time we got to the end of the engagement, I never did get any logs from any of the network devices. However, I had documented my findings (written, as well as with the photo) and had a defensible position, not just for myself, but also for my boss to take up the chain, if the issue ended up going that far.
As a side note, I make it a practice that if I get the sense that something is fishy, or that an engagement could go sideways, I'll call my boss and inform my management chain first, so that they hear it from me. Better that, than the first they hear of any issue is an angry call from a client. This is where notes really help...IR engagements are highly stressful events for everyone involved, and having notes is going to help you when it comes to who said/did what, and when.
Rules
One of the questions Matt addresses in his blog post is the 'rules' of the notes; whenever I've been asked about this, the question has always been, "what's the standard?" My response has always been pretty simple...reproduceability. You need to write your notes to the point that 6 months or a year later, you (or more importantly, someone else) can take the notes and the data, and reproduce the results.
Standards
In fact, I have been asked the question about the "standard" so much over the years that it's become a high-fidelity indicator that notes will not be taken. So far, every single time I've been asked about the "standard" to which notes should be taken, note have not been kept.
When I started with ISS in 2006, I was provided dongles for AccessData FTK, as well as for EnCase 4.22 and 6.19. When I performed work, I noted which application I used right along with what I did...because that was important. When we (our team) determined that one of the built-in functions for a commercial tool was not, in fact, finding all valid credit card numbers (kind of important for PFI work...), we worked with Lance Mueller to get our own function working, and made the use of the result script part of our standard operating (and repeatable) procedure.
Part of the PFI work at the time also included a search for hashes, file names, and a few other indicators. Our notes had to have the date of the work, and our SOP required that just prior to running the searches for those indicators that we pull down the latest-and-greatest copies of the indicator lists.
Why was this important? Well, if someone found something in the data (or on the original system) six or eight months later, we had clear and concise documentation as to what steps were taken when. That way, if the analyst was on leave or on another engagement, a team lead or the director could easily answer the questions. With some simple, clear, and concise notes, the team lead could say, "Yes, but that case was worked 8 months ago, and that indicator was only made available as part of last month's list." Boom. Done. Next.
Application
Another question that comes up is, what application should I use? Well, I started with Notepad, because it was there. I loved it. When I received a laptop from a client and had to remove the hard drive for imaging, I could paste a link to the online instructions I followed, and I could download the instructions and keep them in a separate file, or print them out and keep them in a folder. URL link or printed out, I had an "appendix" to my notes. When I got to the point where I wanted to add photos to my notes, I simply used Write or Word. Depending upon your requirements, you may not need anything schmancy or "high speed, low drag"...just what you've got available may work just fine.
If you're looking for something a little more refined when it comes to keeping notes, take a look at ForensicNotes.
Many of us say/talk about it...we keep notes because at some point in the future, someone's going to have questions. I was in a role where we said that repeatedly...and then it happened. Fully a year after working an engagement, questions came up. Serious questions. Through corporate counsel. And guess what...there were no notes. No one had any clue as to what happened, and by "no one", I'm only referring to those who actually worked the case. Look, we say these things not because we're being silly or we're bored or we just want to be mean...we say them because they're significant, serious, and some of us have seen the damage that can occur to reputation of a company or an individual when notes aren't maintained.
Even with all of this being said, and even with Matt's blog post, there is no doubt in my mind that many DFIR folks are going to continue to say, "I don't want my notes to be discoverable, because a defense attorney would tear them/me apart on the stand." According to Brett Shavers, that's going to happen anyway, with or without notes, so better to have the notes and be able to answer questions with confidence, or at least something more than, "I don't know". The simple fact is that if you're not keeping case notes, you're doing yourself, your fellow analysts, and your client all a huge disservice.
Thursday, August 02, 2018
Some New Items
DFIR Skillz
Brett Shavers posted another great article in which he discussed a much-needed skill in DFIR, albeit one that isn't taught in any courses. That is, communicating to others. If you really think about it, this is incredibly, critically, vitally important. What good is it to have a good, great, or even the best threat intel or DFIR analyst, if they are unable to communicate with others and share their findings? And I'm not talking about just the end results, but also being able to clearly articulate what led to those findings. What is it that you're seeing, for example, that indicates that there's an adversary active in an environment, versus a bunch of persistence mechanisms kicking off when systems are booted? Can you articulate your reasoning, and can you articulate where the gaps are, as well?
Something to keep in mind...there is a distinct difference between being not able to clearly delineate or share findings, and simply being unwilling to do so.
DFIR Skillz - Tech Skillz
A great way to develop technical analysis DFIR skills is to practice technical analysis DFIR skills. There are a number of DFIR challenge images posted online and available for download that you can use to practice skills.
The CFReDS data leakage case provides a great opportunity to work with different types of data from a Windows 7 system, as well as from external devices.
The LoneWolf scenario at the DigitalCorpora site is pretty fascinating, as it allows you to practice using a number of tools, such as hindsight, Volatility, bulk_extractor, etc. The scenario includes an image of a Win 10 laptop with a user profile that includes browser (Chrome, IE) history, a hibernation file, a memory dump, a page file, a swap file, etc. This scenario and the accompanying data was produced by Thomas Moore, as his final project for one of Simson Garfinkel's courses at GMU. The challenge in this scenario will be learning from the image, having not taken the course.
Ali Hadi, PhD, makes a number of datasets available for download. I especially like challenge #1, as it's a great opportunity to try your hand at various analysis tasks, such as using Yara to detect webshells, etc. There are also a couple of other really cool things you can do with the available data; many thanks to @binaryz0ne for providing the scenarios and the datasets.
These are just a few examples of what's available; perhaps the best way to really get the most from these scenarios is to work with a mentor. I can see that many enthusiasts will download the images, maybe start down the road a bit, but not really get anywhere meaningful due to road blocks of some kind. Having someone that you can bounce ideas off ("how does this analysis plan look?"), seek guidance from, etc., would be a great way to move beyond where you are now, and really expand your skill sets.
Blogging
DFIRDudes (Hadar and Martin) have kicked off (here's the tweet announcing it) a new blog with an inaugural post on StartupInfo files. This is a great idea, because as Brett had mentioned previously, there's a lot of great info that is peppered on to Twitter that really needs a much more permanent home someplace, one that's a bit roomier (and more persistent) than 280 characters. The first sentence of the first post really sets the tone, and gives the blog a good push away from the dock.
If you're on the fence about starting a blog, check out Phill's post, because his answer is a resounding "yes".
Retail Breaches
HelpNetSecurity had a fascinating article recently that discusses a surge in retail breaches. While this data is based on survey, I still find it fascinating that in 2018, more organizations haven't pursued the implementations of instrumentation and visibility into their infrastructures that would provide for early detection and response. And yes, I do understand that the focus of the survey (and as a result, the data) is retailers, organizations that wouldn't necessarily have the budget for such things.
Perhaps the most telling part of the article is that, "Security spending is up but not aligning with risk."
RegRipper updates
I've received some great contributions to the repository over the past month or so; many, many thanks to those who've contributed plugins!
Brett Shavers posted another great article in which he discussed a much-needed skill in DFIR, albeit one that isn't taught in any courses. That is, communicating to others. If you really think about it, this is incredibly, critically, vitally important. What good is it to have a good, great, or even the best threat intel or DFIR analyst, if they are unable to communicate with others and share their findings? And I'm not talking about just the end results, but also being able to clearly articulate what led to those findings. What is it that you're seeing, for example, that indicates that there's an adversary active in an environment, versus a bunch of persistence mechanisms kicking off when systems are booted? Can you articulate your reasoning, and can you articulate where the gaps are, as well?
Something to keep in mind...there is a distinct difference between being not able to clearly delineate or share findings, and simply being unwilling to do so.
DFIR Skillz - Tech Skillz
A great way to develop technical analysis DFIR skills is to practice technical analysis DFIR skills. There are a number of DFIR challenge images posted online and available for download that you can use to practice skills.
The CFReDS data leakage case provides a great opportunity to work with different types of data from a Windows 7 system, as well as from external devices.
The LoneWolf scenario at the DigitalCorpora site is pretty fascinating, as it allows you to practice using a number of tools, such as hindsight, Volatility, bulk_extractor, etc. The scenario includes an image of a Win 10 laptop with a user profile that includes browser (Chrome, IE) history, a hibernation file, a memory dump, a page file, a swap file, etc. This scenario and the accompanying data was produced by Thomas Moore, as his final project for one of Simson Garfinkel's courses at GMU. The challenge in this scenario will be learning from the image, having not taken the course.
Ali Hadi, PhD, makes a number of datasets available for download. I especially like challenge #1, as it's a great opportunity to try your hand at various analysis tasks, such as using Yara to detect webshells, etc. There are also a couple of other really cool things you can do with the available data; many thanks to @binaryz0ne for providing the scenarios and the datasets.
These are just a few examples of what's available; perhaps the best way to really get the most from these scenarios is to work with a mentor. I can see that many enthusiasts will download the images, maybe start down the road a bit, but not really get anywhere meaningful due to road blocks of some kind. Having someone that you can bounce ideas off ("how does this analysis plan look?"), seek guidance from, etc., would be a great way to move beyond where you are now, and really expand your skill sets.
Blogging
DFIRDudes (Hadar and Martin) have kicked off (here's the tweet announcing it) a new blog with an inaugural post on StartupInfo files. This is a great idea, because as Brett had mentioned previously, there's a lot of great info that is peppered on to Twitter that really needs a much more permanent home someplace, one that's a bit roomier (and more persistent) than 280 characters. The first sentence of the first post really sets the tone, and gives the blog a good push away from the dock.
If you're on the fence about starting a blog, check out Phill's post, because his answer is a resounding "yes".
Retail Breaches
HelpNetSecurity had a fascinating article recently that discusses a surge in retail breaches. While this data is based on survey, I still find it fascinating that in 2018, more organizations haven't pursued the implementations of instrumentation and visibility into their infrastructures that would provide for early detection and response. And yes, I do understand that the focus of the survey (and as a result, the data) is retailers, organizations that wouldn't necessarily have the budget for such things.
Perhaps the most telling part of the article is that, "Security spending is up but not aligning with risk."
RegRipper updates
I've received some great contributions to the repository over the past month or so; many, many thanks to those who've contributed plugins!
Thursday, July 05, 2018
LNK "Toolmarks"
LNK Artifacts and "Toolmarks"
I've discussed LNK files in this blog a number of times over the years, mostly focusing on the file format. In one instance (from 5 years ago), the focus was on parsers, and specifically about determining devices that had been connected to the system, as when it comes to illicit images/videos, such things can determine the difference between "possession" and "production". This sort of information can also be used to address such topics as data exfiltration.
Last year, I started looking at LNK files (here, and then shortly thereafter, here...) from a different perspective; that of LNK files being sent as email attachments, or somehow being delivered to a "victim".
So, what? Why does this matter? Most users of Windows systems are very familiar with LNK files, or "Windows shortcuts", as they pertain to user actions on a system, or software installations. Both of these generally result in an LNK file being created. And if you follow malware write-ups or threat intel blog posts, you'll very likely see mention of some malware variant or targeted adversary creating an LNK file in a user's StartUp folder as a means of remaining persistent on the system. These LNK files are usually created on the compromised system, through the use of the local API, so other than their location, there's nothing too terribly interesting about them.
However, when an adversary sends a Windows shortcut file as an email attachment (or through some other mechanism) that LNK file contains information about their (the adversary's) system. The folks at JPCERT/CC mentioned this about a year and half ago (the folks at NViso Labs said something similar, as well); if the LNK file was created (via the MS API) on the adversary's system, then it likely contains the NetBIOS name of the system, the MAC address, the volume serial number, and the code page number (although in the research I've done so far, I have yet to find an LNK file with the code page number populated). While anyone of these values may be seen as trivial, all of them together can be employed to great effect by researchers. For example, using the NetBIOS name, MAC address, and VSN (such as illustrated in this blog post), I wrote a Yara rule that I deployed as a VirusTotal retro-hunt, in order to look for other examples; I ended up with several dozen responses in very short order. An example of such a rule is the "shellphish" Yara rule illustrated in this blog post. In the case of the "shellphish" rule, the LNK file that I initially looked at also included a SID in the Property Store Data Block, and including it in the retro-hunt served to minimize false positives (i.e., hits on files that contained the other byte sequences, but were not what I was looking for).
Using an LNK file parser available online, I parsed a LNK file with an embedded, base64-encoded Powershell command, and saw the following:
[Distributed Link Tracker Properties]
Version: 0
NetBIOS name: RAA6AFwAYQBhAC4Aã\ J G
Droid volume identifier: 69426764-4841-414d-0000-000000000032
Droid file identifier: e09ff242-e6d1-9945-a75d-f512f84510dc
Birth droid volume identifier: 8e3691fc-e7be-bc11-6200-1fe2f6735632
Birth droid file identifier: e09ff242-e6d1-9945-a75d-f512f84510dc
MAC address: f5:12:f8:45:10:dc
UUID timestamp: 03/17/3700 (13:54:42.551) [UTC]
UUID sequence number: 10077
The file was moved to a new volume.
Okay, so, this is very different. Usually, the "NetBIOS name" is 16 bytes, which is what my own parser looks for; however, in this case, what is the "machine ID" consumes a good bit more than 16 bytes, as illustrated in figure 1.
In this case, as you can see in figure 1, the "machine ID" is 31 bytes in size, with the first 24 bytes being "RAA6AFwAYQBhAC4AdgBiAHM", and the last 7 being all zeros. As the size of the Tracker Data Block (4 bytes at 0xca3) remains consistent at 96 bytes, the larger-than-expected machine ID presents a parsing problem. The "droids" start at offset 0xcd2, and are identical, so due to the larger machine ID, the Tracker Data Block itself "ends" part way through that section of data, at offset 0xd02. This leaves the remaining 15 bytes of the final droid (which ends at 0xd11) unparsed...notice how the math works out? The machine ID is 15 bytes larger than it should be, and as such, everything is "off" (per the MS file format documentation) by 15 bytes.
Normally, my parser returns output that appears as follows:
***TrackerDataBlock***
Machine ID : admin-pc
New Droid ID Time : Tue Sep 19 12:57:20 2017 UTC
New Droid ID Seq Num : 11190
New Droid Node ID : 08:00:27:3a:ce:83
Birth Droid ID Time : Tue Sep 19 12:57:20 2017 UTC
Birth Droid ID Seq Num: 11190
Birth Droid Node ID : 08:00:27:3a:ce:83
The above output is from an LNK file that fully meets the file format specification. During my research into some of these malicious LNK files, I added the ability to provide debugging information so that anomalies would be more apparent, rather than "hidden" behind the parsing process.
From the LNK file from which the hex dump in figure 1 was extracted, we can still extract and manually parse the droids; as the ObjectIDs are based on the UUID version 1 format (discussed in this blog post), we can use this information to our advantage in our research, extracting the node IDs (MAC addresses), etc. Interestingly enough, though, the larger machine ID doesn't seem to have an effect on the command embedded within the LNK file; having sections of the file format that do not comply with the specification doesn't seem to affect the performance of the LNK file.
I began wondering if the larger machine ID field might be a "toolmark" of some kind, an artifact of whatever process or application that had been used to create the LNK file. I also began looking at a range (I hesitate to qualify the range with "wide"...) of LNK files found online, particularly those that ran external commands (encoded Powershell commands, bitsadmin commands, etc.), as well as looking for tools, applications, or processes that would allow someone to create arbitrary, malicious LNK files. At this point in time, I haven't yet found one that produces "toolmarks" similar to what's seen in figure 1.
The machine ID/NetBIOS name, user SID, VSN, and MAC address are all artifacts from the adversary's system that remain within the LNK file when it is sent to a target. The folks at ProofPoint discussed one or two means of deploying LNK files, which could result in some very interesting artifacts. I'm sure that if enough specifically-malicious LNK files were examined, we'd be able to pull out "toolmarks" from such things as specific applications/tools or processes used to create (or modify) the LNK files, or perhaps even identify misbehaving applications that create LNK files on non-Windows systems.
I've discussed LNK files in this blog a number of times over the years, mostly focusing on the file format. In one instance (from 5 years ago), the focus was on parsers, and specifically about determining devices that had been connected to the system, as when it comes to illicit images/videos, such things can determine the difference between "possession" and "production". This sort of information can also be used to address such topics as data exfiltration.
Last year, I started looking at LNK files (here, and then shortly thereafter, here...) from a different perspective; that of LNK files being sent as email attachments, or somehow being delivered to a "victim".
So, what? Why does this matter? Most users of Windows systems are very familiar with LNK files, or "Windows shortcuts", as they pertain to user actions on a system, or software installations. Both of these generally result in an LNK file being created. And if you follow malware write-ups or threat intel blog posts, you'll very likely see mention of some malware variant or targeted adversary creating an LNK file in a user's StartUp folder as a means of remaining persistent on the system. These LNK files are usually created on the compromised system, through the use of the local API, so other than their location, there's nothing too terribly interesting about them.
However, when an adversary sends a Windows shortcut file as an email attachment (or through some other mechanism) that LNK file contains information about their (the adversary's) system. The folks at JPCERT/CC mentioned this about a year and half ago (the folks at NViso Labs said something similar, as well); if the LNK file was created (via the MS API) on the adversary's system, then it likely contains the NetBIOS name of the system, the MAC address, the volume serial number, and the code page number (although in the research I've done so far, I have yet to find an LNK file with the code page number populated). While anyone of these values may be seen as trivial, all of them together can be employed to great effect by researchers. For example, using the NetBIOS name, MAC address, and VSN (such as illustrated in this blog post), I wrote a Yara rule that I deployed as a VirusTotal retro-hunt, in order to look for other examples; I ended up with several dozen responses in very short order. An example of such a rule is the "shellphish" Yara rule illustrated in this blog post. In the case of the "shellphish" rule, the LNK file that I initially looked at also included a SID in the Property Store Data Block, and including it in the retro-hunt served to minimize false positives (i.e., hits on files that contained the other byte sequences, but were not what I was looking for).
Using an LNK file parser available online, I parsed a LNK file with an embedded, base64-encoded Powershell command, and saw the following:
[Distributed Link Tracker Properties]
Version: 0
NetBIOS name: RAA6AFwAYQBhAC4Aã\ J G
Droid volume identifier: 69426764-4841-414d-0000-000000000032
Droid file identifier: e09ff242-e6d1-9945-a75d-f512f84510dc
Birth droid volume identifier: 8e3691fc-e7be-bc11-6200-1fe2f6735632
Birth droid file identifier: e09ff242-e6d1-9945-a75d-f512f84510dc
MAC address: f5:12:f8:45:10:dc
UUID timestamp: 03/17/3700 (13:54:42.551) [UTC]
UUID sequence number: 10077
The file was moved to a new volume.
Okay, so, this is very different. Usually, the "NetBIOS name" is 16 bytes, which is what my own parser looks for; however, in this case, what is the "machine ID" consumes a good bit more than 16 bytes, as illustrated in figure 1.
 |
| Fig 1: Hex dump from LNK file; Tracker Data Block |
In this case, as you can see in figure 1, the "machine ID" is 31 bytes in size, with the first 24 bytes being "RAA6AFwAYQBhAC4AdgBiAHM", and the last 7 being all zeros. As the size of the Tracker Data Block (4 bytes at 0xca3) remains consistent at 96 bytes, the larger-than-expected machine ID presents a parsing problem. The "droids" start at offset 0xcd2, and are identical, so due to the larger machine ID, the Tracker Data Block itself "ends" part way through that section of data, at offset 0xd02. This leaves the remaining 15 bytes of the final droid (which ends at 0xd11) unparsed...notice how the math works out? The machine ID is 15 bytes larger than it should be, and as such, everything is "off" (per the MS file format documentation) by 15 bytes.
Normally, my parser returns output that appears as follows:
***TrackerDataBlock***
Machine ID : admin-pc
New Droid ID Time : Tue Sep 19 12:57:20 2017 UTC
New Droid ID Seq Num : 11190
New Droid Node ID : 08:00:27:3a:ce:83
Birth Droid ID Time : Tue Sep 19 12:57:20 2017 UTC
Birth Droid ID Seq Num: 11190
Birth Droid Node ID : 08:00:27:3a:ce:83
The above output is from an LNK file that fully meets the file format specification. During my research into some of these malicious LNK files, I added the ability to provide debugging information so that anomalies would be more apparent, rather than "hidden" behind the parsing process.
From the LNK file from which the hex dump in figure 1 was extracted, we can still extract and manually parse the droids; as the ObjectIDs are based on the UUID version 1 format (discussed in this blog post), we can use this information to our advantage in our research, extracting the node IDs (MAC addresses), etc. Interestingly enough, though, the larger machine ID doesn't seem to have an effect on the command embedded within the LNK file; having sections of the file format that do not comply with the specification doesn't seem to affect the performance of the LNK file.
I began wondering if the larger machine ID field might be a "toolmark" of some kind, an artifact of whatever process or application that had been used to create the LNK file. I also began looking at a range (I hesitate to qualify the range with "wide"...) of LNK files found online, particularly those that ran external commands (encoded Powershell commands, bitsadmin commands, etc.), as well as looking for tools, applications, or processes that would allow someone to create arbitrary, malicious LNK files. At this point in time, I haven't yet found one that produces "toolmarks" similar to what's seen in figure 1.
The machine ID/NetBIOS name, user SID, VSN, and MAC address are all artifacts from the adversary's system that remain within the LNK file when it is sent to a target. The folks at ProofPoint discussed one or two means of deploying LNK files, which could result in some very interesting artifacts. I'm sure that if enough specifically-malicious LNK files were examined, we'd be able to pull out "toolmarks" from such things as specific applications/tools or processes used to create (or modify) the LNK files, or perhaps even identify misbehaving applications that create LNK files on non-Windows systems.
Friday, June 29, 2018
Updates
I just pushed three new plugins up to the RegRipper plugin repository, two written by Gabriele Zambelli (photos_win10.pl, msedge_win10.pl), and I wrote source_os.pl, to address the "When Windows Lies" issue that Mari brought up last year.
Addendum, 30 June: Pushed a new plugin from M. Godfrey, named "imgburn1.pl" to the repo this afternoon. Many thanks to Michael (and Gabriele) for writing and submitting plugins!
Addendum, 2 July: Thanks to input and test data from Mitch Impey, I was able to quickly update not only shellbags.pl and shellbags_tln.pl, but also comdlg32.pl. Providing sample/test data makes troubleshooting and updating current plugins, or creating new ones, a much quicker and more efficient process. Thanks, Mitch!
Addendum, 5 July: Many thinks to Micah Jones for sharing the dafupnp.pl plugin he wrote created! This is a plugin that pulls information about media streaming devices from the System hive. Thanks, Micah, for the great work and for sharing the plugin. Also, based on the data that Micah shared, I updated the bthport.pl plugin, as well.
Also, I added bthport_tln.pl to the repository, as well. This will help in performing timeline analysis for such things as data exfil via Bluetooth devices.
Addendum, 28 July: I committed two new plugins from Micah Jones to the repo this morning, thunderbirdinstalled.pl and mzthunderbird.pl. Thanks, Micah!
Addendum, 30 June: Pushed a new plugin from M. Godfrey, named "imgburn1.pl" to the repo this afternoon. Many thanks to Michael (and Gabriele) for writing and submitting plugins!
Addendum, 2 July: Thanks to input and test data from Mitch Impey, I was able to quickly update not only shellbags.pl and shellbags_tln.pl, but also comdlg32.pl. Providing sample/test data makes troubleshooting and updating current plugins, or creating new ones, a much quicker and more efficient process. Thanks, Mitch!
Addendum, 5 July: Many thinks to Micah Jones for sharing the dafupnp.pl plugin he wrote created! This is a plugin that pulls information about media streaming devices from the System hive. Thanks, Micah, for the great work and for sharing the plugin. Also, based on the data that Micah shared, I updated the bthport.pl plugin, as well.
Also, I added bthport_tln.pl to the repository, as well. This will help in performing timeline analysis for such things as data exfil via Bluetooth devices.
Addendum, 28 July: I committed two new plugins from Micah Jones to the repo this morning, thunderbirdinstalled.pl and mzthunderbird.pl. Thanks, Micah!
Thursday, June 21, 2018
More about EDR/MDR
On the heels of my previous post on the topic, from my perspective, there still seems to be something of a misconception within the market as a whole as to the value of EDR/MDR.
During conversations on the EDR/MDR topic, one of the questions we hear quite often is, "Do you detect X?", with "X" being some newly-identified virus or exploit. I think that the reason we hear this question so often is that EDR/MDR is still somewhat new in the minds of the marketplace, and most organizations are still trying to visualize and really understand the concept, and how it applies to them. The way we most often go about doing that sort of thing is by finding something we're familiar with, and start by building a comparison relationship there. Unfortunately, starting with AV as the comparison doesn't really get us to where we need to be, in part because this is a whole new way of looking at things.
And believe me, I do understand how difficult it is in today's marketplace to really understand what's out there. A while back, I was in a sales presentation, and a sales rep was going through the slide pack they'd been provided by marketing; at one point, the client just came right out and said, "...yes, everyone says that, every other vendor we've spoken to has said the same exact thing. How are you different?" They were asking this question because they were trying to get beyond the initial fluff and down to, okay, how is this vendor's product better for us and our needs? Now, the folks we were talking to were actually very mature, in the sense that they had already identified their EDR needs, and actually had been working with an EDR product with a subset of their infrastructure, so they were essentially trying to make an apples-to-apples comparison of products.
As recently as last week, I was encouraged via a marketing email to sign up for a webinar, and one of the inducement statements in the corresponding blog post (linked in the email) was along the lines of, "...you should be detecting ransomware the moment it reaches out to the C2 server."
Hhhhmmm...but what if we could detect the issue before that point? What if you could detect the initial behaviors that lead to a malware infection, and block the activity at that point, rather than waiting to try to detect the malware itself? If we focused our efforts earlier in the attack cycle, we could impose greater pain on the attacker, raising the level of effort required on their part, and forcing them to change their tactics.
So what do I mean by this? Every day, thousands (millions?) of employees log into their corporate computer systems, launch Outlook, and read their email. Part of this may involve opening attachments, including MSWord documents and Excel spreadsheets. As such, it's normal and expected to see a process tree that goes from the user logging in (Windows Explorer), to launching Outlook, and then Outlook includes whichever attachment is opened as a child process. It looks something like this:
explorer.exe
|__Outlook.exe
|__winword.exe
Now, when a user is sent a phishing email with a weaponized attachment, the user may be prompted to click the "Enable Content" button in MSWord in order to allow any embedded macros to run; once this happens, we generally see something like the command prompt (cmd.exe), or something else (PowerShell, etc.) running as a child process of MSWord. This is ( a ) never a good thing, ( b ) easy to detect, and ( c ) equally trivial to block. Here's what that might look like:
explorer.exe
|__Outlook.exe
|__winword.exe
|__cmd.exe /c powershell.exe...
|__powershell.exe...
Here's a good example, shared by Phil Burdette some time ago, albeit without the Outlook component.
The point is that this behavior can be detected and alerted on, and then action can be take at the point where winword.exe spawns a command shell as a subprocess. As such, if we're blocking processes from executing at that point, then we're not even getting to the point where PowerShell or WScript or BITSAdmin or whatever is used to download the malicious stuff to the compromised system. With the right instrumentation, you may also be able to isolate the system on the network after having blocked the malicious behavior. That way, instead of sending someone a ticket telling them that they have to respond, and them getting it at some point in the future (even as much as a few minutes is enough for the adversary to burrow their way into your infrastructure), all access is immediately disabled.
This is where MDR solutions come into play. With the right endpoint technology in place, an MDR not only monitors what's going on, but is able to take threat intelligence developed from monitoring their entire client base, and apply is across all monitored clients. This means that every client benefits from what was gleaned and developed from any one client, and they benefit immediately.
What this ultimately leads to is much earlier detection of malicious activity, and a much quicker response to that activity, such that reporting is obviated. After all, if you're able to detect and respond to an adversary much earlier in their attack cycle, and you're able to cycle through the OODA loop faster than the adversary, then you're able to prevent access to any "sensitive data". If that sensitive data isn't accessed, then you don't have to report. Also, you've got a record of activity that demonstrates that you were able to respond to, contain, and eradicate the adversary.
During conversations on the EDR/MDR topic, one of the questions we hear quite often is, "Do you detect X?", with "X" being some newly-identified virus or exploit. I think that the reason we hear this question so often is that EDR/MDR is still somewhat new in the minds of the marketplace, and most organizations are still trying to visualize and really understand the concept, and how it applies to them. The way we most often go about doing that sort of thing is by finding something we're familiar with, and start by building a comparison relationship there. Unfortunately, starting with AV as the comparison doesn't really get us to where we need to be, in part because this is a whole new way of looking at things.
And believe me, I do understand how difficult it is in today's marketplace to really understand what's out there. A while back, I was in a sales presentation, and a sales rep was going through the slide pack they'd been provided by marketing; at one point, the client just came right out and said, "...yes, everyone says that, every other vendor we've spoken to has said the same exact thing. How are you different?" They were asking this question because they were trying to get beyond the initial fluff and down to, okay, how is this vendor's product better for us and our needs? Now, the folks we were talking to were actually very mature, in the sense that they had already identified their EDR needs, and actually had been working with an EDR product with a subset of their infrastructure, so they were essentially trying to make an apples-to-apples comparison of products.
As recently as last week, I was encouraged via a marketing email to sign up for a webinar, and one of the inducement statements in the corresponding blog post (linked in the email) was along the lines of, "...you should be detecting ransomware the moment it reaches out to the C2 server."
Hhhhmmm...but what if we could detect the issue before that point? What if you could detect the initial behaviors that lead to a malware infection, and block the activity at that point, rather than waiting to try to detect the malware itself? If we focused our efforts earlier in the attack cycle, we could impose greater pain on the attacker, raising the level of effort required on their part, and forcing them to change their tactics.
So what do I mean by this? Every day, thousands (millions?) of employees log into their corporate computer systems, launch Outlook, and read their email. Part of this may involve opening attachments, including MSWord documents and Excel spreadsheets. As such, it's normal and expected to see a process tree that goes from the user logging in (Windows Explorer), to launching Outlook, and then Outlook includes whichever attachment is opened as a child process. It looks something like this:
explorer.exe
|__Outlook.exe
|__winword.exe
Now, when a user is sent a phishing email with a weaponized attachment, the user may be prompted to click the "Enable Content" button in MSWord in order to allow any embedded macros to run; once this happens, we generally see something like the command prompt (cmd.exe), or something else (PowerShell, etc.) running as a child process of MSWord. This is ( a ) never a good thing, ( b ) easy to detect, and ( c ) equally trivial to block. Here's what that might look like:
explorer.exe
|__Outlook.exe
|__winword.exe
|__cmd.exe /c powershell.exe...
|__powershell.exe...
Here's a good example, shared by Phil Burdette some time ago, albeit without the Outlook component.
The point is that this behavior can be detected and alerted on, and then action can be take at the point where winword.exe spawns a command shell as a subprocess. As such, if we're blocking processes from executing at that point, then we're not even getting to the point where PowerShell or WScript or BITSAdmin or whatever is used to download the malicious stuff to the compromised system. With the right instrumentation, you may also be able to isolate the system on the network after having blocked the malicious behavior. That way, instead of sending someone a ticket telling them that they have to respond, and them getting it at some point in the future (even as much as a few minutes is enough for the adversary to burrow their way into your infrastructure), all access is immediately disabled.
This is where MDR solutions come into play. With the right endpoint technology in place, an MDR not only monitors what's going on, but is able to take threat intelligence developed from monitoring their entire client base, and apply is across all monitored clients. This means that every client benefits from what was gleaned and developed from any one client, and they benefit immediately.
What this ultimately leads to is much earlier detection of malicious activity, and a much quicker response to that activity, such that reporting is obviated. After all, if you're able to detect and respond to an adversary much earlier in their attack cycle, and you're able to cycle through the OODA loop faster than the adversary, then you're able to prevent access to any "sensitive data". If that sensitive data isn't accessed, then you don't have to report. Also, you've got a record of activity that demonstrates that you were able to respond to, contain, and eradicate the adversary.
Monday, June 18, 2018
Updates
I've had a bunch of draft blog posts sitting around, and for some of them, particularly the really technical ones, I thought, "...ah, no one's gonna read this...", so I opted for another medium, or I simply deleted them. However, I decided to throw a couple of them in together, into one post, just so I could complete my thoughts and get them out there, and do a bit of housekeeping with respect to my blog drafts.
Publishing
Brett Shavers recently posted some interesting content on the topic of publishing in DFIR. While DFIR doesn't necessary follow the "publish or perish" adage most often seen in academia, Brett does have some very good points.
To Brett's point about "lack of contributors", this is the reason why efforts like Into The Boxes project never really took off...you can't sustain a community-based project if folks within the community aren't willing to contribute.
By the way, I still have my inaugural hard copy of "Into The Boxes #1", knowing full well that one day it's going to be part of my DFIR museum, right alongside my MS-DOS install diskettes, my original Windows XP install CDs, and an AOL installation CD!
Something else that Brett mentioned in his post was "peer review". Oddly enough, I've been engaged in a conversation with someone else in the DFIR community about this very topic, particularly as it applies to analysis findings. In my experience, peer reviews within the community are spotty, at best. We all know that team member that we can go to, because they'll turn around a 40 page report draft in 15 minutes, saying just that it "looks good." And we also know that team member we can go to and rely on to catch stuff we may have missed.
Blog-a-Day Challenge
Speaking of publishing, it looks as if over the last couple of weeks a number of folks have decided to take the Zeltser Challenge, that is to post a blog a day for an entire year. Not only has David Cowen picked it back up (he's done it before...), but others have joined the party, as well. For example, Stacey has started The Knowledge Bean and decided to partake in the challenge. Tony at Archer Forensics has picked up the mantle, as well, and is off and running.
If anyone else in DFIR is doing something like this...blog-a-day, or even blog-a-week, let me know...I'd like to check it out.
Oh, and tying this back to the previous topic, something Tony mentioned in one of the blog posts:
I would solicit everyone to do that deeper dive research to further the field.
Agreed, 1000%.
New Plugins
Well, let's see...what's new on the plugin front? So, I recently received one updated plugin (lastloggedon.pl) and a new plugin (utorrent.pl) from Michael Godfrey (author information included in the plugins), and uploaded them to the repository. I also added jumplistdata.pl, which is based on this finding from Costas K. Finally, I created execpolicy.pl, a plugin to check the PowerShell ExecutionPolicy value, if it exists...some folks have said that adversaries have been observed modifying the Registry value to that they can bypass the execution policies in order to run their code, albeit not from the command line.
Not a new plugin, but I also updated the license for RegRipper to the MIT license, at the request of some folks at AWS.
Tool Usage
Mari published a blog article recently, which I thought was great...not just because Mari's great at sharing information in an easy-to-understand and repeatable manner, but more so due to how her post discussed tool usage. There any number of DFIR sites out there, web sites and blogs alike, that are full of tool listings...here's this tool, and here's this tool. Great. It's like shop class, with all of the tools hanging on the peg board, on their specific hooks, over their specific silhouettes.
The question folks should have is, great, but how can I best employ those tools to complete the goals of my investigation in a complete, thorough, accurate, and timely manner?
If you're looking for something to blog about...there you go. There are potentially hundreds or thousands of blog posts based on just that single theme, that one topic.
Publishing
Brett Shavers recently posted some interesting content on the topic of publishing in DFIR. While DFIR doesn't necessary follow the "publish or perish" adage most often seen in academia, Brett does have some very good points.
To Brett's point about "lack of contributors", this is the reason why efforts like Into The Boxes project never really took off...you can't sustain a community-based project if folks within the community aren't willing to contribute.
By the way, I still have my inaugural hard copy of "Into The Boxes #1", knowing full well that one day it's going to be part of my DFIR museum, right alongside my MS-DOS install diskettes, my original Windows XP install CDs, and an AOL installation CD!
Something else that Brett mentioned in his post was "peer review". Oddly enough, I've been engaged in a conversation with someone else in the DFIR community about this very topic, particularly as it applies to analysis findings. In my experience, peer reviews within the community are spotty, at best. We all know that team member that we can go to, because they'll turn around a 40 page report draft in 15 minutes, saying just that it "looks good." And we also know that team member we can go to and rely on to catch stuff we may have missed.
Blog-a-Day Challenge
Speaking of publishing, it looks as if over the last couple of weeks a number of folks have decided to take the Zeltser Challenge, that is to post a blog a day for an entire year. Not only has David Cowen picked it back up (he's done it before...), but others have joined the party, as well. For example, Stacey has started The Knowledge Bean and decided to partake in the challenge. Tony at Archer Forensics has picked up the mantle, as well, and is off and running.
If anyone else in DFIR is doing something like this...blog-a-day, or even blog-a-week, let me know...I'd like to check it out.
Oh, and tying this back to the previous topic, something Tony mentioned in one of the blog posts:
I would solicit everyone to do that deeper dive research to further the field.
Agreed, 1000%.
New Plugins
Well, let's see...what's new on the plugin front? So, I recently received one updated plugin (lastloggedon.pl) and a new plugin (utorrent.pl) from Michael Godfrey (author information included in the plugins), and uploaded them to the repository. I also added jumplistdata.pl, which is based on this finding from Costas K. Finally, I created execpolicy.pl, a plugin to check the PowerShell ExecutionPolicy value, if it exists...some folks have said that adversaries have been observed modifying the Registry value to that they can bypass the execution policies in order to run their code, albeit not from the command line.
Not a new plugin, but I also updated the license for RegRipper to the MIT license, at the request of some folks at AWS.
Tool Usage
Mari published a blog article recently, which I thought was great...not just because Mari's great at sharing information in an easy-to-understand and repeatable manner, but more so due to how her post discussed tool usage. There any number of DFIR sites out there, web sites and blogs alike, that are full of tool listings...here's this tool, and here's this tool. Great. It's like shop class, with all of the tools hanging on the peg board, on their specific hooks, over their specific silhouettes.
The question folks should have is, great, but how can I best employ those tools to complete the goals of my investigation in a complete, thorough, accurate, and timely manner?
If you're looking for something to blog about...there you go. There are potentially hundreds or thousands of blog posts based on just that single theme, that one topic.
Sunday, June 17, 2018
Coding in DFIR
A while back, I wrote a blog post where I discussed writing my own tools, and why I do it. I have publicly shared the tools I've written, and I was asked to share my thoughts as to why I do it, and how it's "of value" to me, and more importantly, to my workflow. I generally find it very helpful to have tools that fit into and support the workflow I'm using (i.e., timelines), and I also find it very valuable to be able to address issues with the tools (and others) as a result of the available data that's being parsed.
Something I've been interested in for quite some time is the metadata embedded in various file formats used on Windows systems, and this interest has cracked the shell a bit in more than a few cases, and given me just a peak inside of what may be going on when someone creates a file for malicious purposes. I've not only been able to pull apart OLE format MS documents (MS Word .doc files), but also the OLE objects embedded inside the newer .docx format files.
One tool I like to use is Didier Stevens' oledump.py, in part because it provides a great deal of functionality, particularly where it will decompress VBA macros. However, I will also use my own OLE parser, because it pulls some metadata that I tend to find very useful when developing a view into an adversary's activities. Also, there is the potential for additional data to be extracted from areas that other tools simply do not address.
An example of simply metadata extraction came from the Mia Ash persona that Allison Wickoff (an excellent intel analyst at SecureWorks) unraveled. I didn't have much at all to do with the amazing work that Allison did...all I did was look at the metadata associated with a document sent to the victims. However, from that small piece of information came some pretty amazing insights.
Another, much older example of how metadata can be extracted and used comes from the Blair case. That's all I'll say about that one.
Another file format that I've put some work into understanding and unraveling is the LNK file format, which MS has done a very good job of documenting.
There are a number of FOSS tools available for parsing the binary LNK file format that will display the various fields, but I noticed during some recent testing that there were files submitted to VirusTotal that had apparently "done their job" (i.e., been successfully used to infect systems), but the parsing tools failed at various points in dissecting the binary contents of the file. Some tools that did all of their parsing and then displayed the various fields failed completely, and those that displayed the fields as they were parsed appeared to fail only at a certain point. Understanding the file format allowed me to identify where the tools appeared to be failing, and in this way, I'm not simply going back to some who wrote a tool with, "..didn't work." I know exactly what happened and why, and more importantly, can address it. As a result of the work I did, I have also seen that some aspects of these file formats can be abused without degrading the base functionality offered via the format.
This is where coding in DFIR comes in...using a hex editor, I was able to see where and why the tools were having issues, and I could also see that there really wasn't anything that any of the tools could do about. What I mean by that is, when parsing Extra Data Blocks within an LNK file (in particular, the TrackerDataBlock) what would be the "machine ID" or NetBIOS name of the system on which the LNK file was created extends beyond the bounds of the size value for that section. Yes, the machine ID value is of variable length (per the specification) but it also represents the NetBIOS name of a Windows system, so there's an expectation (however inaccurate) that it won't extend beyond the maximum length of a NetBIOS name.
In some of the test cases I observed (files downloaded from VirusTotal using the "tag: lnk" search term), the machine ID field was several bytes longer than expected, pushing the total length of the TrackerDataBlock out beyond the identified length. This causes all tools to fail, and begin reading the droids from the wrong location. In other instances, what would be the machine ID is a string of hex characters that extends beyond the length of the TrackerDataBlock, with no apparent droid fields visible via a hex editor.
These are possibly modifications of some kind, or errors in the tool used to create the LNK files (for an example of such a tool, go here). Either way, could these be considered 'tool marks' that could be used to track LNK files being deployed across campaigns?
Am I suggesting that everyone, every examiner needs to be proficient at coding and knowledgeable of file formats? No, not at all. In this blog post, I'm simply elaborating on a previous response, and illustrating how having an understanding of coding can be helpful.
Other examples of how coding in DFIR is useful include not just being able to automate significant portions of your workflow, but also being able to understand what an attacker may have been trying to achieve. I've engaged in a number of IR engagements over the years where attackers have left batch files or Visual Basic scripts behind, and for the most part, they were easy to understand, and very useful. However, every now and then, there would be a relatively un- or under-used command that required some research, or something "new".
Another example is decoding weaponized MSWord documents. Not long ago, I unraveled a macro embedded in an MSWord document, and having some ability to code not only helped me do the unraveling, but also helped me see what was actually being done. The macro had multiple layers of obfuscation, including base64 encoding, character encoding (i.e., using the character number from an ASCII table instead of the character itself, and decoding via chr()...), as well as a few other tricks. At one point, there was even a base64-encoded string embedded within a script that was, itself, base64 encoded.
So, in summary, having some capability to code, at some level, is extremely valuable within the DFIR community...that, or knowing someone. In fact, having someone (or a few someones) you can go to for assistance is just helpful all around.
Something I've been interested in for quite some time is the metadata embedded in various file formats used on Windows systems, and this interest has cracked the shell a bit in more than a few cases, and given me just a peak inside of what may be going on when someone creates a file for malicious purposes. I've not only been able to pull apart OLE format MS documents (MS Word .doc files), but also the OLE objects embedded inside the newer .docx format files.
One tool I like to use is Didier Stevens' oledump.py, in part because it provides a great deal of functionality, particularly where it will decompress VBA macros. However, I will also use my own OLE parser, because it pulls some metadata that I tend to find very useful when developing a view into an adversary's activities. Also, there is the potential for additional data to be extracted from areas that other tools simply do not address.
An example of simply metadata extraction came from the Mia Ash persona that Allison Wickoff (an excellent intel analyst at SecureWorks) unraveled. I didn't have much at all to do with the amazing work that Allison did...all I did was look at the metadata associated with a document sent to the victims. However, from that small piece of information came some pretty amazing insights.
Another, much older example of how metadata can be extracted and used comes from the Blair case. That's all I'll say about that one.
Another file format that I've put some work into understanding and unraveling is the LNK file format, which MS has done a very good job of documenting.
There are a number of FOSS tools available for parsing the binary LNK file format that will display the various fields, but I noticed during some recent testing that there were files submitted to VirusTotal that had apparently "done their job" (i.e., been successfully used to infect systems), but the parsing tools failed at various points in dissecting the binary contents of the file. Some tools that did all of their parsing and then displayed the various fields failed completely, and those that displayed the fields as they were parsed appeared to fail only at a certain point. Understanding the file format allowed me to identify where the tools appeared to be failing, and in this way, I'm not simply going back to some who wrote a tool with, "..didn't work." I know exactly what happened and why, and more importantly, can address it. As a result of the work I did, I have also seen that some aspects of these file formats can be abused without degrading the base functionality offered via the format.
This is where coding in DFIR comes in...using a hex editor, I was able to see where and why the tools were having issues, and I could also see that there really wasn't anything that any of the tools could do about. What I mean by that is, when parsing Extra Data Blocks within an LNK file (in particular, the TrackerDataBlock) what would be the "machine ID" or NetBIOS name of the system on which the LNK file was created extends beyond the bounds of the size value for that section. Yes, the machine ID value is of variable length (per the specification) but it also represents the NetBIOS name of a Windows system, so there's an expectation (however inaccurate) that it won't extend beyond the maximum length of a NetBIOS name.
In some of the test cases I observed (files downloaded from VirusTotal using the "tag: lnk" search term), the machine ID field was several bytes longer than expected, pushing the total length of the TrackerDataBlock out beyond the identified length. This causes all tools to fail, and begin reading the droids from the wrong location. In other instances, what would be the machine ID is a string of hex characters that extends beyond the length of the TrackerDataBlock, with no apparent droid fields visible via a hex editor.
These are possibly modifications of some kind, or errors in the tool used to create the LNK files (for an example of such a tool, go here). Either way, could these be considered 'tool marks' that could be used to track LNK files being deployed across campaigns?
Am I suggesting that everyone, every examiner needs to be proficient at coding and knowledgeable of file formats? No, not at all. In this blog post, I'm simply elaborating on a previous response, and illustrating how having an understanding of coding can be helpful.
Other examples of how coding in DFIR is useful include not just being able to automate significant portions of your workflow, but also being able to understand what an attacker may have been trying to achieve. I've engaged in a number of IR engagements over the years where attackers have left batch files or Visual Basic scripts behind, and for the most part, they were easy to understand, and very useful. However, every now and then, there would be a relatively un- or under-used command that required some research, or something "new".
Another example is decoding weaponized MSWord documents. Not long ago, I unraveled a macro embedded in an MSWord document, and having some ability to code not only helped me do the unraveling, but also helped me see what was actually being done. The macro had multiple layers of obfuscation, including base64 encoding, character encoding (i.e., using the character number from an ASCII table instead of the character itself, and decoding via chr()...), as well as a few other tricks. At one point, there was even a base64-encoded string embedded within a script that was, itself, base64 encoded.
So, in summary, having some capability to code, at some level, is extremely valuable within the DFIR community...that, or knowing someone. In fact, having someone (or a few someones) you can go to for assistance is just helpful all around.
Tuesday, May 08, 2018
EDR Obviates Compliance
Okay, you'll have to excuse me for the title of this blog post...I needed something to get your attention, and get you to read this, because it's important. I know that stating that "EDR obviates compliance" is going to cause a swirl of emotions in anyone's mind, and my intention was to get you to read on and hear me out; 280 characters simply is not enough to share this line of reasoning.
GDPR is just around the corner, and article 4 of GDPR defines a "personal data breach as"...
...‘personal data breach’ means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed...
Something to be aware of is that this definition includes ransomware, as it includes "access to" and "alteration of".
As security professionals have been saying for quite some time now, breaches of your perimeter are going to happen, it's simply inevitable. However, per GDPR, it's not a reportable breach until something happens with respect to 'personal data'. The simple fact is that without adequate/suitable instrumentation and visibility, you simply won't know if personal data has been accessed during a breach. EDR provides that visibility.
Where Are We Now?
Right now, we're "right of breach". Most organizations are simply unprepared for breaches to occur, and breach identification comes in the form of third-party external notification. This notification comes weeks or even months after the initial intrusion occurred, during with time the dearth of instrumentation and "evidence decay" makes it nearly impossible to definitively determine what the adversary may have done, with any degree of certainty.
The 2018 Nuix Black Report states that 98% of those surveyed stated that they could breach the perimeter of a target organization and exfil data in 15 hrs or less. Compare that to the 2017 Ponemon Institute report that indicated that the 'dwell time' (the time between a breach actually occurring and it being detected) was 191 days, and it's still in the triple digits. I hardly seems far, but that's reality in today's terms.
Where we need to be is "left of breach". We know breaches are going to occur, and we know that clean up is going to be messy, so what we need to do is get ahead of the game and be prepared. It's not unlike boxing...if you step into the ring with gloves on, you know you're going to get hit, so it behooves you to get your gloves up and move around a bit, lessening the impact and effect of your opponent's punches. In cybersecurity, we move "left of breach" by employing monitored EDR (MDR) so that breaches can be detected and responded to early in the adversary's attack cycle, allowing us to contain and eradicate the adversary before they're able to access "critical value data", of CVD. CVD can consist of "personal data", or PII; credit card data, or PCI; healthcare data, or PHI; or it can be intellectual property, or IP. Regardless of what your "CVD" is, the point is that you want to detect, respond to and stop the bad guy before they're able to access it, and the only way you can do that is to instrument your infrastructure for visibility.
Costs
Chris Pogue wrote this blog post, addressing the "cost of breach" topic, almost three years ago. With the help of our wonderful marketing department, I recently gave this webinar on reducing costs associated with breaches. Things haven't changed...breaches are becoming more expensive; more expensive to clean up, more expensive in terms of down-time and lapses in productivity, and more expensive in terms of legal fees and fines.
While researching information for the webinar, one of the things I ran across was the fines that would have been associated with GDPR, had GDPR been in effect at the time that the Equifax breach. In 2016, Equifax reportedly earned $3.145B USD. High end GDPR fines can be "20M euros or 4% of world-wide operating revenue, whichever is greater", bringing the fine to $125.8M USD. That's just the GDPR fine; that does not include direct costs associated with the IR response and investigation, subsequent notification, nor any indirect costs.
On 1 May, Alabama became the 50th US state to enact a data breach notification law, SB 318. As you read over the stipulations regarding reporting detailed in the law, keep in mind that for the 50 US states, everyone is different. If you store or process the personal data for US citizens, the cost associated with simply determining to which states you actually have to report is enormous! And that's before you even report...it doesn't include the actual cost of notification, it's just the cost of determining to whom (which states) you need to report!
EDR/MDR
So where does endpoint detection and response (EDR) come in?
I've been doing DFIR work for about two decades now, and most of the work I've done has been after an incident has occurred. Early on, the work involved a system or two thought to be infected or compromised in some manner, but it was always well after the supposed infection or compromise occurred. In most cases, questions involving things like, "...what data was taken?" simply could not be answered. Either the information to answer the question didn't exist due to evidence decay, or it didn't exist because that information was was never actually recorded or logged.
EDR/MDR solutions allow you to detect a breach early in the adversary's attack cycle, as one of the things monitored by most, if not all, EDR tools is the processes executed on systems. Yes, you get a lot of 'normal' user stuff (allowing you to detect fraud and insider threats), but you also get a detailed look at the adversary's activities.
To see some really good examples of process trees showing what various attacks look like, go to Phil Burdette's Twitter feed. This tweet includes an example of a phish, with the user clicking "Enable Content" on a malicious document, leading to the implant being downloaded via bitsadmin. This tweet illustrates a great example of credential theft. I could go on and on about this, but I think that the point has been made...EDR gives you a level of visibility that you don't get through any other instrumentation.
Where I've used this information to great effect was detecting an adversary's activities within a client's infrastructure several years ago; the tool being used at the time alerted on the use of an archive utility known as "Rar". The adversary had renamed the executable so that it was no longer 'rar.exe', but adding a password to protect the archive is not something the adversary could change, and it's what was detected in this case. So, we had the fact that data was marshaled and archived for exfiltration (along with the password), and we further was that after exfiltrating the archives, the adversary deleted the archived data. However, once we got an image of the system we were able to carve unallocated space and recover a number of the archives, and using the adversary's password, we were able to open the recovered archives and see exactly what data was taken.
Today, the way to address this behavior is that rather than alerting on the condition, instead, block the process itself. And the same thing is true with other adversary behaviors; intelligence gives us excellent insight into adversary behaviors, and using these behaviors, we can implement our EDR solution to alert on some things, but if other specific conditions are met, prevent those actions from completing. We can further isolate the adversary by isolating the system on the network.
In March of this year, the City of Atlanta was hit with Samsam ransomware. Interestingly enough, Secureworks, a security MSSP located within the corporate limits of the city, has a good bit of documentation as to the methodology used by the adversary that deploys the ransomware; had the city had an EDR/MDR solution in place prior to the incident, they would've detected and been able to respond to the initial breach, before the adversary was able to deploy the ransomware.
Benefits
Given all this, the benefits of employing an EDR/MDR solution are:
1. The solution becomes part of your budget. Employing an EDR/MDR solution is something you plan for, and include in your annual budget. Breaches are rarely planned for.
2. You now have definitive data illustrating the actions taken by an adversary prior to your containment and eradication procedures. You have a record of the commands they ran, the actions they took, and hence their behaviors. You know exactly where they are within your infrastructure, and you can track back to how they got there, meaning that you can quickly contain and eradicate them.
3. Due to early detection and response, you now have definite data to support not having to report the breach. Let's say that you detect someone on your network running the "whoami" command; this is a behavior that's been observed in many adversaries. Alerting on this behavior will allow you to respond to the adversary during their initial recon phase, before they're able to perform credential theft, privilege escalation, and lateral movement. All of their activity and behavior is recorded, and it's a short list because you've detected and responded to them very early in their attack cycle. As 'personal data' was not accessed, you've obviated your need to report, and obviated costs associated with fines, notification, clean-up, etc.
GDPR is just around the corner, and article 4 of GDPR defines a "personal data breach as"...
...‘personal data breach’ means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed...
Something to be aware of is that this definition includes ransomware, as it includes "access to" and "alteration of".
As security professionals have been saying for quite some time now, breaches of your perimeter are going to happen, it's simply inevitable. However, per GDPR, it's not a reportable breach until something happens with respect to 'personal data'. The simple fact is that without adequate/suitable instrumentation and visibility, you simply won't know if personal data has been accessed during a breach. EDR provides that visibility.
Where Are We Now?
Right now, we're "right of breach". Most organizations are simply unprepared for breaches to occur, and breach identification comes in the form of third-party external notification. This notification comes weeks or even months after the initial intrusion occurred, during with time the dearth of instrumentation and "evidence decay" makes it nearly impossible to definitively determine what the adversary may have done, with any degree of certainty.
The 2018 Nuix Black Report states that 98% of those surveyed stated that they could breach the perimeter of a target organization and exfil data in 15 hrs or less. Compare that to the 2017 Ponemon Institute report that indicated that the 'dwell time' (the time between a breach actually occurring and it being detected) was 191 days, and it's still in the triple digits. I hardly seems far, but that's reality in today's terms.
Where we need to be is "left of breach". We know breaches are going to occur, and we know that clean up is going to be messy, so what we need to do is get ahead of the game and be prepared. It's not unlike boxing...if you step into the ring with gloves on, you know you're going to get hit, so it behooves you to get your gloves up and move around a bit, lessening the impact and effect of your opponent's punches. In cybersecurity, we move "left of breach" by employing monitored EDR (MDR) so that breaches can be detected and responded to early in the adversary's attack cycle, allowing us to contain and eradicate the adversary before they're able to access "critical value data", of CVD. CVD can consist of "personal data", or PII; credit card data, or PCI; healthcare data, or PHI; or it can be intellectual property, or IP. Regardless of what your "CVD" is, the point is that you want to detect, respond to and stop the bad guy before they're able to access it, and the only way you can do that is to instrument your infrastructure for visibility.
Costs
Chris Pogue wrote this blog post, addressing the "cost of breach" topic, almost three years ago. With the help of our wonderful marketing department, I recently gave this webinar on reducing costs associated with breaches. Things haven't changed...breaches are becoming more expensive; more expensive to clean up, more expensive in terms of down-time and lapses in productivity, and more expensive in terms of legal fees and fines.
While researching information for the webinar, one of the things I ran across was the fines that would have been associated with GDPR, had GDPR been in effect at the time that the Equifax breach. In 2016, Equifax reportedly earned $3.145B USD. High end GDPR fines can be "20M euros or 4% of world-wide operating revenue, whichever is greater", bringing the fine to $125.8M USD. That's just the GDPR fine; that does not include direct costs associated with the IR response and investigation, subsequent notification, nor any indirect costs.
On 1 May, Alabama became the 50th US state to enact a data breach notification law, SB 318. As you read over the stipulations regarding reporting detailed in the law, keep in mind that for the 50 US states, everyone is different. If you store or process the personal data for US citizens, the cost associated with simply determining to which states you actually have to report is enormous! And that's before you even report...it doesn't include the actual cost of notification, it's just the cost of determining to whom (which states) you need to report!
EDR/MDR
So where does endpoint detection and response (EDR) come in?
I've been doing DFIR work for about two decades now, and most of the work I've done has been after an incident has occurred. Early on, the work involved a system or two thought to be infected or compromised in some manner, but it was always well after the supposed infection or compromise occurred. In most cases, questions involving things like, "...what data was taken?" simply could not be answered. Either the information to answer the question didn't exist due to evidence decay, or it didn't exist because that information was was never actually recorded or logged.
EDR/MDR solutions allow you to detect a breach early in the adversary's attack cycle, as one of the things monitored by most, if not all, EDR tools is the processes executed on systems. Yes, you get a lot of 'normal' user stuff (allowing you to detect fraud and insider threats), but you also get a detailed look at the adversary's activities.
To see some really good examples of process trees showing what various attacks look like, go to Phil Burdette's Twitter feed. This tweet includes an example of a phish, with the user clicking "Enable Content" on a malicious document, leading to the implant being downloaded via bitsadmin. This tweet illustrates a great example of credential theft. I could go on and on about this, but I think that the point has been made...EDR gives you a level of visibility that you don't get through any other instrumentation.
Where I've used this information to great effect was detecting an adversary's activities within a client's infrastructure several years ago; the tool being used at the time alerted on the use of an archive utility known as "Rar". The adversary had renamed the executable so that it was no longer 'rar.exe', but adding a password to protect the archive is not something the adversary could change, and it's what was detected in this case. So, we had the fact that data was marshaled and archived for exfiltration (along with the password), and we further was that after exfiltrating the archives, the adversary deleted the archived data. However, once we got an image of the system we were able to carve unallocated space and recover a number of the archives, and using the adversary's password, we were able to open the recovered archives and see exactly what data was taken.
Today, the way to address this behavior is that rather than alerting on the condition, instead, block the process itself. And the same thing is true with other adversary behaviors; intelligence gives us excellent insight into adversary behaviors, and using these behaviors, we can implement our EDR solution to alert on some things, but if other specific conditions are met, prevent those actions from completing. We can further isolate the adversary by isolating the system on the network.
In March of this year, the City of Atlanta was hit with Samsam ransomware. Interestingly enough, Secureworks, a security MSSP located within the corporate limits of the city, has a good bit of documentation as to the methodology used by the adversary that deploys the ransomware; had the city had an EDR/MDR solution in place prior to the incident, they would've detected and been able to respond to the initial breach, before the adversary was able to deploy the ransomware.
Benefits
Given all this, the benefits of employing an EDR/MDR solution are:
1. The solution becomes part of your budget. Employing an EDR/MDR solution is something you plan for, and include in your annual budget. Breaches are rarely planned for.
2. You now have definitive data illustrating the actions taken by an adversary prior to your containment and eradication procedures. You have a record of the commands they ran, the actions they took, and hence their behaviors. You know exactly where they are within your infrastructure, and you can track back to how they got there, meaning that you can quickly contain and eradicate them.
3. Due to early detection and response, you now have definite data to support not having to report the breach. Let's say that you detect someone on your network running the "whoami" command; this is a behavior that's been observed in many adversaries. Alerting on this behavior will allow you to respond to the adversary during their initial recon phase, before they're able to perform credential theft, privilege escalation, and lateral movement. All of their activity and behavior is recorded, and it's a short list because you've detected and responded to them very early in their attack cycle. As 'personal data' was not accessed, you've obviated your need to report, and obviated costs associated with fines, notification, clean-up, etc.
Monday, May 07, 2018
Tools, Books, Lessons Learned
Tools
As part of my Sunday morning reading a bit ago, I was fascinated by an evolving tweet thread...Eric recently tweeted some random threat hunting advice involving shimcache data. In response, Nick tweeted regarding an analytic approach to using shimcache/appcompatcache data, at scale, along with AmCache data. Nick also provided a link to the FireEye blog post that describes their AppCompatProcessor tool.
I really like this approach, and I think that it's a fantastic step forward, not only in single system analytics, analyzing one system through the traditional, "dead box" analysis, but also with respect to an enterprise-wide approach to threat hunting and response. In many ways, threat hunting and response is the next logical step in DFIR work, isn't it? Taking what you learned from one system and expanding it to many systems just kinda makes sense, and it looks as though what the FireEye folks did was take what they learned from many single system examinations and developed a process, with an accompanying tool, from that information.
From even a single system analysis approach, there are still a number of analysts within the community who either aren't parsing the AppCompatCache data as a matter of course, or they're misinterpreting the time stamp data all together. Back in Dec, 2016, Matt Bromiley wrote an article describing some of the important aspects of the AppCompatCache data ("important" with respect to interpretation of the data). Also, be sure tocheck out read thoroughly the section named "AppCompatSecrets" here, as well as Luis's article here. A correct understanding of the data and it's context is important going forward.
From an enterprise perspective, there are tools that do nothing more than collect/parse this data from systems, but do not provide any analytics to the data itself, in short, simply dumping this massive trove of data on the analyst. The analytic approach described by the FireEye folks is similar in nature to the Hamming distance, something I learned about while taking Dr. Hamming's seminar at NPS; in short, the closer the temporal execution of two entries (smaller Hamming distance), the stronger the tcorr value. This can be applied to great effect as a threat hunting technique across the enterprise. In the case of AppCompatCache data, the time stamp does not indicate temporal execution; rather, it's a combination of a flag value and the position of the entry, in the order that it's stored within the Registry value. The "temporal" aspect, in this case, refers to the location of entries in the data with respect to each other.
This can also be applied on a single system dead box analysis, when you look at it as a system, and include not just the System hive, but the System hive in the RegBack folder, as well as any that exist in VSCs, as well as within a memory dump.
I'd recently blogged about using several Registry and Registry-like artifacts in a much smaller approach to "analytics", looking at the use and correlation of multiple sources of data on a single system, with my base assumption being that of single system dead box analysis. I figured, hey, it's a place to start.
Getting a Book Published
I recently had an opportunity to read Scar's blog post entitled, Finding a Publisher For Your Book. I found it fascinating because what she wrote about is not too dissimilar from my own experiences.
I have not read her book, Windows Forensic Cookbook. In fact, I wasn't aware of it until recently. Once I found out about it, I checked the Amazon site and didn't see any reviews of the book; I'm not surprised...after all, this is the DFIR "community"...but I did hope to get a sense of the material within the book. So, this isn't a book review, but rather commentary in solidarity with her experiences.
Like Scar, I've put a lot of work into writing a manuscript, only to get the proofs back for review and thinking...what? In one instance, every single instance of "plugin" had been changed to "plug-in" in a chapter. Uh...no. My response back to the copy editor was simply to state at the being of the chapter, "...change it back...all of it."
Scar's comments about expectations caught my attention, as well, particularly when the publisher wanted a chapter review turned around in 48 hrs. What?!? This is one of those things you have to be prepared for when working with publishers...they simply do not understand their suppliers, at all. A publisher or editor works on getting multiple books out, that's what they do all day. However, those of us writing books and providing material do other things all day, and write books when we have time. That's right...we do the stuff during the day that makes us qualified to write books, and then actually get to write the books in our copious "free time", after putting in a full day or week of work. These crazy deadlines are something I've pushed against, more so since I've developed greater credibility with the publisher by writing more books. When my tech editor is working full days just like everyone else and gets a 35+ page chapter with a demand to have the review returned within 48 hrs, that's simply an unrealistic expectation that needs to be addressed up front.
I've been writing books for a while now...it didn't occur to me just how long I've been doing it until last week. I have a book in the process of being published right now...I'm waiting on the proofs to come back for review...and I submitted a prospectus recently for another book, and the reviews of the proposal I sent in have started coming back. One reviewer referred to WFA 1/e, published in 2005; this means that I actually started working on it late in 2003, or really in 2004. And that wasn't my first book. All of this is to say that when I see someone write a blog post where they share their experiences in writing a book and getting it published, what I find most interesting about it is that nothing seems to have changed. As such, a lot of what Scar wrote in her blog post rings very true, even to this day.
Finally, I've mentioned this before but I'll say it again...over the years, I've heard stories about issues folks have had working with publishers; I've had some of my own, but I like to think that I've learned from them. Some folks don't get beyond the proposal stage for their book, and some folks have gotten to a signed contract, but drop out due to apparently arbitrary changes made by the editorial staff, after the contract was signed by both parties. What I had proposed to the publisher I have worked with is to create a liaison position, one where I would work directly with authors (singles, groups) to help them navigate the apparent labyrinth of going from a blank sheet of paper to a published book, using what I've learned over the years. This never really went anywhere, in part due to the turnover with the publisher...once I had found a champion for the idea, that person left the company. The fact that after attempting to do this three times and not succeeding, and that the publisher hasn't come back to me to pursue it, tells me that they (the publisher) are happy with the status quo.
If you're interested in writing a book, you don't have to be. Read over Scar's blog post, ask questions, etc., before you make a decision to commit to writing a book. It isn't easy, but it can be done. If your main fear against writing a book is that someone else is going to read it and be critical, keep in mind that no one will be as passionate as you about what you write.
Lessons Learned
I was engaged in an exchange with a trusted and respected colleague recently, and he said something to me that really struck a chord...he said that if I wanted to progress in the direction we were discussing, I've got to stop "giving stuff away for free". He was referring to my blog (I think), and his point was well taken. If you're like me, and really (REALLY) enjoy the work...the discovery, the learning, solving a problem in what may be a unique manner, etc...then what does something like writing books and blog posts get you? I'm not sure what it gets others, but it doesn't lead to being able to conduct analysis, that's for sure. I mean, why should it, right...if I put it in writing what I did or would do, any someone else can replicate it (like a recipe for tollhouse cookies) then why reach out and say, "Hey, Harlan...I could really use your help on this...", or "...can you analyze these images for malicious activity..."?
As part of my Sunday morning reading a bit ago, I was fascinated by an evolving tweet thread...Eric recently tweeted some random threat hunting advice involving shimcache data. In response, Nick tweeted regarding an analytic approach to using shimcache/appcompatcache data, at scale, along with AmCache data. Nick also provided a link to the FireEye blog post that describes their AppCompatProcessor tool.
I really like this approach, and I think that it's a fantastic step forward, not only in single system analytics, analyzing one system through the traditional, "dead box" analysis, but also with respect to an enterprise-wide approach to threat hunting and response. In many ways, threat hunting and response is the next logical step in DFIR work, isn't it? Taking what you learned from one system and expanding it to many systems just kinda makes sense, and it looks as though what the FireEye folks did was take what they learned from many single system examinations and developed a process, with an accompanying tool, from that information.
From even a single system analysis approach, there are still a number of analysts within the community who either aren't parsing the AppCompatCache data as a matter of course, or they're misinterpreting the time stamp data all together. Back in Dec, 2016, Matt Bromiley wrote an article describing some of the important aspects of the AppCompatCache data ("important" with respect to interpretation of the data). Also, be sure to
This can also be applied on a single system dead box analysis, when you look at it as a system, and include not just the System hive, but the System hive in the RegBack folder, as well as any that exist in VSCs, as well as within a memory dump.
I'd recently blogged about using several Registry and Registry-like artifacts in a much smaller approach to "analytics", looking at the use and correlation of multiple sources of data on a single system, with my base assumption being that of single system dead box analysis. I figured, hey, it's a place to start.
Getting a Book Published
I recently had an opportunity to read Scar's blog post entitled, Finding a Publisher For Your Book. I found it fascinating because what she wrote about is not too dissimilar from my own experiences.
I have not read her book, Windows Forensic Cookbook. In fact, I wasn't aware of it until recently. Once I found out about it, I checked the Amazon site and didn't see any reviews of the book; I'm not surprised...after all, this is the DFIR "community"...but I did hope to get a sense of the material within the book. So, this isn't a book review, but rather commentary in solidarity with her experiences.
Like Scar, I've put a lot of work into writing a manuscript, only to get the proofs back for review and thinking...what? In one instance, every single instance of "plugin" had been changed to "plug-in" in a chapter. Uh...no. My response back to the copy editor was simply to state at the being of the chapter, "...change it back...all of it."
Scar's comments about expectations caught my attention, as well, particularly when the publisher wanted a chapter review turned around in 48 hrs. What?!? This is one of those things you have to be prepared for when working with publishers...they simply do not understand their suppliers, at all. A publisher or editor works on getting multiple books out, that's what they do all day. However, those of us writing books and providing material do other things all day, and write books when we have time. That's right...we do the stuff during the day that makes us qualified to write books, and then actually get to write the books in our copious "free time", after putting in a full day or week of work. These crazy deadlines are something I've pushed against, more so since I've developed greater credibility with the publisher by writing more books. When my tech editor is working full days just like everyone else and gets a 35+ page chapter with a demand to have the review returned within 48 hrs, that's simply an unrealistic expectation that needs to be addressed up front.
I've been writing books for a while now...it didn't occur to me just how long I've been doing it until last week. I have a book in the process of being published right now...I'm waiting on the proofs to come back for review...and I submitted a prospectus recently for another book, and the reviews of the proposal I sent in have started coming back. One reviewer referred to WFA 1/e, published in 2005; this means that I actually started working on it late in 2003, or really in 2004. And that wasn't my first book. All of this is to say that when I see someone write a blog post where they share their experiences in writing a book and getting it published, what I find most interesting about it is that nothing seems to have changed. As such, a lot of what Scar wrote in her blog post rings very true, even to this day.
Finally, I've mentioned this before but I'll say it again...over the years, I've heard stories about issues folks have had working with publishers; I've had some of my own, but I like to think that I've learned from them. Some folks don't get beyond the proposal stage for their book, and some folks have gotten to a signed contract, but drop out due to apparently arbitrary changes made by the editorial staff, after the contract was signed by both parties. What I had proposed to the publisher I have worked with is to create a liaison position, one where I would work directly with authors (singles, groups) to help them navigate the apparent labyrinth of going from a blank sheet of paper to a published book, using what I've learned over the years. This never really went anywhere, in part due to the turnover with the publisher...once I had found a champion for the idea, that person left the company. The fact that after attempting to do this three times and not succeeding, and that the publisher hasn't come back to me to pursue it, tells me that they (the publisher) are happy with the status quo.
If you're interested in writing a book, you don't have to be. Read over Scar's blog post, ask questions, etc., before you make a decision to commit to writing a book. It isn't easy, but it can be done. If your main fear against writing a book is that someone else is going to read it and be critical, keep in mind that no one will be as passionate as you about what you write.
Lessons Learned
I was engaged in an exchange with a trusted and respected colleague recently, and he said something to me that really struck a chord...he said that if I wanted to progress in the direction we were discussing, I've got to stop "giving stuff away for free". He was referring to my blog (I think), and his point was well taken. If you're like me, and really (REALLY) enjoy the work...the discovery, the learning, solving a problem in what may be a unique manner, etc...then what does something like writing books and blog posts get you? I'm not sure what it gets others, but it doesn't lead to being able to conduct analysis, that's for sure. I mean, why should it, right...if I put it in writing what I did or would do, any someone else can replicate it (like a recipe for tollhouse cookies) then why reach out and say, "Hey, Harlan...I could really use your help on this...", or "...can you analyze these images for malicious activity..."?
Monday, April 09, 2018
Mommy, where do plugins come from?
This is one of those questions kids have been asking their parents throughout history, and in more recent times, those parents may have resorted to a book. Just sayin'.
Well, they come from three general sources, really, none of which involves a stork or a cabbage leaf.
Asking
Recently, there were a couple of requests for functionality to be added to RegRipper. One was for the ability to automatically update the default profiles in RegRipper. I was speaking with someone recently, and demonstrating the RegRipper extension that had been added to Nuix's Workbench product. As part of the discussion, I explained that I do not update the default profiles when I create new plugins (something I've mentioned a number of times in this blog), as I don't want to overwrite any customized profiles folks have made to their installations. This person then asked, "...can you add the ability to update the default profiles automatically?" I thought for a minute and realized that rip already has about 2/3 of the code I would need to do exactly that. So, I opened an editor, used that code to populate a hash of arrays, and then wrote the lists of plugin names, each to their own file. Boom. Done.
The other "feature" was for a new plugin to be created. Someone I know reached out to me to say that they'd found value in a particular Registry key/value during an investigation, and that it might make a good plugin to retrieve the value in question. This person didn't initially provide any test data, and when they did, it was an exported .reg file; I know it sounds easy enough to handle, but this adds several additional steps (i.e., open a VM, transfer the .reg file to it, import the .reg file into a hive, then shut down the VM, open the .vmdk file in FTK Imager, and extract the hive...), as well as a level of uncertainty (are there variations based on the version of Windows, etc.), to the testing process.
Not having data to test on makes it difficult to write a plugin, as well as test the plugin before releasing it.
Intel from IR engagements
So, where do other plugins come from? Similar to the request for the new plugin, sometimes I'll find something during an examination that might make a good plugin. For example, during an examination, we found a Registry value of interest, and as such, I added the key LastWrite times from the user's NTUSER.DAT hive to a timeline, using regtime.exe. For context, I did the same for the Software hive from that system, and as an aside, found some interesting Registry keys/values associated with the installed AV product. In this instance, the keys and values were related to the responder's activities, but writing a plugin (or two) to extract data from the Registry keys/values would facilitate research activities, and as such, make it easier to determine their nature and context.
Interestingly enough, this is how RegRipper started, and was the source of most of the plugins I've written in the past decade.
Online research
Another source of plugins is OSINT, and online research.
For example, FireEye recently released their 2018 M-Trends report, and page 23 includes a Registry key that an attacker modified to hide their activity, by adding a folder to the AV exclusion list. If I had data on which to test a plugin, I'd write one; online research indicates that there's a key within the path that may vary, and as such, I'd need a bit better understanding of the path in order to write a useful plugin.
Oddly enough, I don't think I have ever received a request for a plugin based on something published online, via a blog post, or an annual report. I don't see (or know) everything, and it's likely that I may simply have not seen that post or report.
Another analysis aspect that RegRipper can be used for is the check or verify system configuration. For example, see this Microsoft documentation regarding making remote calls to the local SAM database; including a plugin to extract these values may help an analyst narrow down the original attack vector, or at least identify possibilities.
Well, they come from three general sources, really, none of which involves a stork or a cabbage leaf.
Asking
Recently, there were a couple of requests for functionality to be added to RegRipper. One was for the ability to automatically update the default profiles in RegRipper. I was speaking with someone recently, and demonstrating the RegRipper extension that had been added to Nuix's Workbench product. As part of the discussion, I explained that I do not update the default profiles when I create new plugins (something I've mentioned a number of times in this blog), as I don't want to overwrite any customized profiles folks have made to their installations. This person then asked, "...can you add the ability to update the default profiles automatically?" I thought for a minute and realized that rip already has about 2/3 of the code I would need to do exactly that. So, I opened an editor, used that code to populate a hash of arrays, and then wrote the lists of plugin names, each to their own file. Boom. Done.
The other "feature" was for a new plugin to be created. Someone I know reached out to me to say that they'd found value in a particular Registry key/value during an investigation, and that it might make a good plugin to retrieve the value in question. This person didn't initially provide any test data, and when they did, it was an exported .reg file; I know it sounds easy enough to handle, but this adds several additional steps (i.e., open a VM, transfer the .reg file to it, import the .reg file into a hive, then shut down the VM, open the .vmdk file in FTK Imager, and extract the hive...), as well as a level of uncertainty (are there variations based on the version of Windows, etc.), to the testing process.
Not having data to test on makes it difficult to write a plugin, as well as test the plugin before releasing it.
Intel from IR engagements
So, where do other plugins come from? Similar to the request for the new plugin, sometimes I'll find something during an examination that might make a good plugin. For example, during an examination, we found a Registry value of interest, and as such, I added the key LastWrite times from the user's NTUSER.DAT hive to a timeline, using regtime.exe. For context, I did the same for the Software hive from that system, and as an aside, found some interesting Registry keys/values associated with the installed AV product. In this instance, the keys and values were related to the responder's activities, but writing a plugin (or two) to extract data from the Registry keys/values would facilitate research activities, and as such, make it easier to determine their nature and context.
Interestingly enough, this is how RegRipper started, and was the source of most of the plugins I've written in the past decade.
Online research
Another source of plugins is OSINT, and online research.
For example, FireEye recently released their 2018 M-Trends report, and page 23 includes a Registry key that an attacker modified to hide their activity, by adding a folder to the AV exclusion list. If I had data on which to test a plugin, I'd write one; online research indicates that there's a key within the path that may vary, and as such, I'd need a bit better understanding of the path in order to write a useful plugin.
Oddly enough, I don't think I have ever received a request for a plugin based on something published online, via a blog post, or an annual report. I don't see (or know) everything, and it's likely that I may simply have not seen that post or report.
Another analysis aspect that RegRipper can be used for is the check or verify system configuration. For example, see this Microsoft documentation regarding making remote calls to the local SAM database; including a plugin to extract these values may help an analyst narrow down the original attack vector, or at least identify possibilities.
Friday, April 06, 2018
Updates
Based on some feedback I received recently, I updated RegRipper's rip.pl (and the corresponding .exe, of course) to include the "-uP" switch.
What this switch does is run through all of the plugins, determine to which hives they apply, and the automatically update the default profiles with those plugins. As I've stated in the past, when I create a new plugin, I do not update that appropriate profile...I just add the plugin to the repository. If you want to run all of the plugins available for the NTUSER.DAT hive against all NTUSER.DAT hives you get, run rip.exe with the "-uP" switch, and the profile named "ntuser" will include all of those plugins, EXCEPT those with "_tln" in their name.
This switch will create or overwrite (if they already exist) profiles named for the hives (lower case, without ".dat" at the end). This does NOT affect any custom profiles you've created, unless they use the same names.
I recently received a request from someone to create a new plugin to retrieve the IE Search Scopes. The 'searchscopes.pl' plugin was added to the repository today, along with the updated rip.pl/.exe mentioned above.
Something I wanted to point out about both of these updates...they started with someone asking. That's it. I don't use RegRipper's profiles for the analysis work I do, but I know that others do. If you use the GUI, then that's pretty much what you use...you use profiles, rather than individual plugins. The profiles are also valuable when using the RegRipper extension added to the Nuix Workbench product (fact sheet); the extension relies on a mapping of the hive type to the RegRipper profile. You can edit/update the profiles themselves, or you can create your own custom profiles and edit the mapping file (JSON, just open it in Notepad...). I showed the extension to someone, and they asked, "hey, can you create a tool that automatically updates the default profiles?"
The same is true with the searchscopes.pl plugin...someone said, hey, there's this thing that I found useful during an investigation, it might make a good plugin. Boom. Done.
If you've been thinking about something along these lines, or trying to find a way to do it manually, maybe there's a way to do it in an automated fashion. Sometimes, the smallest interaction can lead to a big result. Don't isolate yourself on your own island.
What this switch does is run through all of the plugins, determine to which hives they apply, and the automatically update the default profiles with those plugins. As I've stated in the past, when I create a new plugin, I do not update that appropriate profile...I just add the plugin to the repository. If you want to run all of the plugins available for the NTUSER.DAT hive against all NTUSER.DAT hives you get, run rip.exe with the "-uP" switch, and the profile named "ntuser" will include all of those plugins, EXCEPT those with "_tln" in their name.
This switch will create or overwrite (if they already exist) profiles named for the hives (lower case, without ".dat" at the end). This does NOT affect any custom profiles you've created, unless they use the same names.
I recently received a request from someone to create a new plugin to retrieve the IE Search Scopes. The 'searchscopes.pl' plugin was added to the repository today, along with the updated rip.pl/.exe mentioned above.
Something I wanted to point out about both of these updates...they started with someone asking. That's it. I don't use RegRipper's profiles for the analysis work I do, but I know that others do. If you use the GUI, then that's pretty much what you use...you use profiles, rather than individual plugins. The profiles are also valuable when using the RegRipper extension added to the Nuix Workbench product (fact sheet); the extension relies on a mapping of the hive type to the RegRipper profile. You can edit/update the profiles themselves, or you can create your own custom profiles and edit the mapping file (JSON, just open it in Notepad...). I showed the extension to someone, and they asked, "hey, can you create a tool that automatically updates the default profiles?"
The same is true with the searchscopes.pl plugin...someone said, hey, there's this thing that I found useful during an investigation, it might make a good plugin. Boom. Done.
If you've been thinking about something along these lines, or trying to find a way to do it manually, maybe there's a way to do it in an automated fashion. Sometimes, the smallest interaction can lead to a big result. Don't isolate yourself on your own island.
Saturday, March 31, 2018
DFIR Analysis and EDR/MDR Solutions
There is only so much the DFIR analysis can do.
There it is, I said it. And it's especially true when the DFIR analysis is the result of external third party incident notification, which we ultimately determine to come months after the incident originally occurred.
Some artifacts exist forever. Until they don't. Some artifacts are recorded and exist for an unspecified and indeterminate period of time...nanoseconds, microseconds, weeks, or months. Processes execute, finish, and the memory they used is freed for use by another process. Text files exist until they are deleted, and the last modification times on the files remain the same until the next time they're modified. Windows Event Logs record events, but some event logs "roll over" more quickly than others; events in some may exist for only a few days, while events in others may exist for weeks or even months. As time passes, artifact clusters corrode to the point where, by the time DFIR analysts get the data for analysis, their ability to definitively answer questions is severely hampered.
The 2017 Ponemon Institute Data Breach Report indicates an average "dwell time" (the time between initial breach and discovery of the breach) of 191 days. The Nuix 2018 Black Report findings indicate that professional red teamers/pen testers report that they can target, compromise, and exfil data within 15 hrs. Hardly seems fair, particularly when you consider that if legitimate, scheduled pen tests go undetected, what chance do we have of detecting an unscheduled, uninvited intruder?
Some artifacts are created, are extremely transient (although they do exist), but are never recorded. An example of this is process command lines; if an adversary runs the "whoami" command as part of their initial attempts to orient themselves, that process exists for a very short time, and then the memory used gets freed for later use. By default, this is not recorded, so it ceases to exist very quickly, and the ceases to be available a short time later. The same is true when an intruder runs the command "net user /add" to create a user account on the system; the command runs, and the command line no longer exists. Yes, the user account is created, so the results of the command persist...but the command line itself, which likely included the password for the account, is no longer available. Finally, when the adversary stages files or data for exfiltration, many times they'll use rar.exe (often renamed) to archive the collected data with a password...the command line for the process will include the password, but once the command has completed, the plain text password issued at the command line is no longer available.
Several years ago, I was working a targeted threat response engagement, and we'd observed the adversary staging data for exfiltration. We alerted on the command line used...it was rar.exe, although the executable had been renamed. The full command line included the password that the adversary used, and was recorded by the EDR/MDR solution. We acquired an image of the system, and through analysis determined that the archive files were no longer visible within the "active" file system. As such, we carved unallocated space for RAR archives and were able to open the twelve archives we retrieved, using the password recorded in the command line used to archive the files. The web server logs definitively illustrated that the files had been exfiltrated (the IIS logs included the requested file name, number of bytes transferred, and the success code of "200"), and we had several of the archives themselves; other deleted archives have enough sectors overwritten that we were not able to successful recover the entire files.
That's a great example of how an EDR/MDR solution can be so powerful in today's world. Also, consider this recent Tanium blog post regarding the Samsam ransomware, the same ransomware family that recently hit the City of Atlanta...using the EDR/MDR solution to detect malicious actor activity prior to them deploying the ransomware, such as during their initial orientation and recon phase, means that you have a better chance of inhibiting, hampering, or completely obviating their end goal.
Finally, EDR/MDR solutions become budget items; I'm pretty sure that Equifax never budgeted for their breach, or budgeted enough. So, not only do you detect breaches early in the attack cycle, but with an IR plan, you can also respond in such a way as to prevent the adversary from accessing whatever it is they're after, obviating compliance and regulatory issues, notification, and keeping costs down.
There it is, I said it. And it's especially true when the DFIR analysis is the result of external third party incident notification, which we ultimately determine to come months after the incident originally occurred.
Some artifacts exist forever. Until they don't. Some artifacts are recorded and exist for an unspecified and indeterminate period of time...nanoseconds, microseconds, weeks, or months. Processes execute, finish, and the memory they used is freed for use by another process. Text files exist until they are deleted, and the last modification times on the files remain the same until the next time they're modified. Windows Event Logs record events, but some event logs "roll over" more quickly than others; events in some may exist for only a few days, while events in others may exist for weeks or even months. As time passes, artifact clusters corrode to the point where, by the time DFIR analysts get the data for analysis, their ability to definitively answer questions is severely hampered.
The 2017 Ponemon Institute Data Breach Report indicates an average "dwell time" (the time between initial breach and discovery of the breach) of 191 days. The Nuix 2018 Black Report findings indicate that professional red teamers/pen testers report that they can target, compromise, and exfil data within 15 hrs. Hardly seems fair, particularly when you consider that if legitimate, scheduled pen tests go undetected, what chance do we have of detecting an unscheduled, uninvited intruder?
Some artifacts are created, are extremely transient (although they do exist), but are never recorded. An example of this is process command lines; if an adversary runs the "whoami" command as part of their initial attempts to orient themselves, that process exists for a very short time, and then the memory used gets freed for later use. By default, this is not recorded, so it ceases to exist very quickly, and the ceases to be available a short time later. The same is true when an intruder runs the command "net user /add" to create a user account on the system; the command runs, and the command line no longer exists. Yes, the user account is created, so the results of the command persist...but the command line itself, which likely included the password for the account, is no longer available. Finally, when the adversary stages files or data for exfiltration, many times they'll use rar.exe (often renamed) to archive the collected data with a password...the command line for the process will include the password, but once the command has completed, the plain text password issued at the command line is no longer available.
Several years ago, I was working a targeted threat response engagement, and we'd observed the adversary staging data for exfiltration. We alerted on the command line used...it was rar.exe, although the executable had been renamed. The full command line included the password that the adversary used, and was recorded by the EDR/MDR solution. We acquired an image of the system, and through analysis determined that the archive files were no longer visible within the "active" file system. As such, we carved unallocated space for RAR archives and were able to open the twelve archives we retrieved, using the password recorded in the command line used to archive the files. The web server logs definitively illustrated that the files had been exfiltrated (the IIS logs included the requested file name, number of bytes transferred, and the success code of "200"), and we had several of the archives themselves; other deleted archives have enough sectors overwritten that we were not able to successful recover the entire files.
That's a great example of how an EDR/MDR solution can be so powerful in today's world. Also, consider this recent Tanium blog post regarding the Samsam ransomware, the same ransomware family that recently hit the City of Atlanta...using the EDR/MDR solution to detect malicious actor activity prior to them deploying the ransomware, such as during their initial orientation and recon phase, means that you have a better chance of inhibiting, hampering, or completely obviating their end goal.
Finally, EDR/MDR solutions become budget items; I'm pretty sure that Equifax never budgeted for their breach, or budgeted enough. So, not only do you detect breaches early in the attack cycle, but with an IR plan, you can also respond in such a way as to prevent the adversary from accessing whatever it is they're after, obviating compliance and regulatory issues, notification, and keeping costs down.
Subscribe to:
Posts (Atom)