The 2015 M-Trends Report states that the median number of days that threat groups were present in a victim's network before detection was 205 days, which is down 24 days from 2013. But that's the median number of days...the longest persistence was 2,982 days. That's over 8 years. The report also states that 69% of organizations were informed of the breach by an external entity.
The 2015 TrustWave Global Security Report indicates that 81% of companies did not detect breaches on their own, and that the median length of time it took to detect a breach was 86 days.
What do these numbers tell us? They tell us that the organizations in question did not detect the breaches, but when they called in consultants to assist, those consultants found evidence of the breaches that allowed them to identify for how long (to a point, of course) that the intruders had persisted within the infrastructure. I'm going to go out on a limb here and just say that I recognize that the consultants may not have been able to trace the breach information back to the initial infection vector (IIV) in every case, so the numbers in the report are likely just a little fuzzy.
What the numbers tell us is that the consultants, based on their combined experience, knowledge, and methodologies, were able to find indicators and artifacts that others did not. This means that the local IT staff either wasn't looking, or didn't have a complete understanding of what to look for.
The numbers in the reports are supported by my own experiences, as well as those of a myriad of other responders. A while back, I worked on an engagement during which we were able to trace the adversary's activities back to the original phishing email and attached weaponized PDF. The emails had been received 21 months before we had been called. I've done analysis on breaches where indicators went back two years or more, and we were never able to track down the IIV.
The numbers also tell us that the adage that attackers need to be right 1 out of 100 times and defenders need to be right 100 out of 100 times doesn't hold, and that it's a myth. What artifacts did the consultants who provided input to the reports find, and could administrators of the compromised infrastructure have found those artifacts, as well, if they'd been looking? Based on my own personal experiences, I would say that the answer is a definite yes.
By now, we are all well aware that prevention doesn't work, that regardless of how many technical measures we put in place, that as long as people are involved in some way, at some point someone will make their way into an infrastructure. So what we need to do is include detection and response; put our protection mechanisms in place, monitor them, look/hunt for issues throughout our infrastructure, and be ready to take some sort of action when issues are found.
In my previous blog post, I shared some thoughts on hunting, in short, describing, in general terms, what folks can look for within their environments. One person commented (via Twitter) that I should spend less time talking about it, and more time listing those artifacts that hunters should look for.
So what should you look for? Check out this video of Lee's presentation...he shares a lot of great information. Much like the information here, or in any of the HowTo blog posts from July, 2013. That's a start. Eventmap.txt has some interesting tips, as do many RegRipper plugins. Want more? Take a hard look at your threat intelligence...if you're getting it from a vendor, does it give you what you need? How about the threat intel you're developing internally? Similarly, does it meet your needs? MD5 hashes and IP addresses aren't going to get you as far as TTPs, if you have the processes and methodologies to find those TTPs.
Tuesday, June 23, 2015
Monday, June 22, 2015
Hunting, and Knowing What To Hunt For
Like many others of my generation, when I was a kid I'd go and play outside for hours and hours. Sometimes, while running through the woods, I'd see trash...but seeing it often, I wouldn't think much of it. Sometimes it was a tire in the creek, and other times it might be bottles or cigarette butts in a small cluster.
When I went through my initial military training, we spent a lot of time in the outdoors, but during the first 6 months, there was no real "this is what to look for training". It wasn't until a couple of years later, when I returned to be an instructor that the course was teaching new officers the difference between moving through the woods during the day and at night.
Much later, after my military service ended, I got engaged in horseback riding, particularly trail riding. Anyone who's ever done this knows that you become more aware of your surroundings, for a variety of reasons, but most importantly, the safety of your horse, you, and those you may be riding with. You develop an awareness of your surroundings; what's moving near you, and what's further away. Are there runners or walks with dogs (or children in strollers) down the trail? Sometimes you can be warned of the impending approach of others not so much visually, as by what you hear or smell (some riders like to smoke while they're riding). You can tell what is or might be in the area by visual observation (scat, droppings, etc.), as well as listening, and even smell. Why is this important? There's a lot that can spook a horse...horses will smell a carcass well before a human will, and as you ride up, a gaggle of vultures might suddenly take flight. Depending on your horse's temperament, a flock of turkey hens running through a field might spook them or just catch their attention.
If it's recently rained in the area where I'm riding, I'll visually sweep the ground looking for footprints and signs of animals and people. If I see what appear to be fresh impressions of running shoes with dog paw prints near by, I might be looking for a walker or runner with a dog. Most runners have a sense of courtesy to slow down to a walk and may be even say something when approaching horses from the rear. Most...not all. And not everyone who walks a dog really thinks about whether their dog is habituated to horses, or even how the dog will reach when they see horses. I'll also look for signs of deer, because they usually (albeit not always) move in groups. More than once in the springtime, I've come across a fawn coiled up in the tall grass...deer teach their fawns to remain very still, regardless of the circumstances, while they go off to forage. More than once I've seen the fawn well before the fawn has lost its nerve and suddenly bolted from its hiding place.
Now, because of this level of awareness, I had an interesting experience several years ago while hiking with friends at the base of Mount Rainier. At the park entrance, there was a small lake with signs prohibiting fishing, and a sign telling hikers what to do if they spotted a bear. We hiked about 3 1/2 miles to a small meadow with wild blueberries growing. The entire way out and back, there were NO signs of animal life...no insects, no sounds of birds or squirrels. No scat or markings of any kind. The absence of any and all fauna was very extremely evident, and more than a bit odd.
So what?
Okay...so what's my point? If you're familiar with the environment, and aware of your surroundings while performing DFIR work, and know what should be there, you know what to look for, as well as what data sources to go to if you're looking for suspicious activity. It's all about knowing what to hunt for when you're hunting. This is particularly true if you're performing hunting operations in your own environment; however, it can also be applied in cases where you're a consultant (like me), engaging with an unfamiliar infrastructure.
In a recent presentation (BrightTalk, may require registration) at InfoSecurity Europe 2015, Lee Lawson discussed some of the indicators that are very likely available to you right now, particularly if you've done nothing to modify the default audit configuration on Windows systems.
Not long ago, the folks at Rapid7 shared this video, describing four indicators you could use to detect lateral movement within your infrastructure. Unfortunately, two of them are not logged as a result of the default audit configuration of Windows systems, and the presenter doesn't mention alternate Windows Event Log source/ID pairs you can look for instead.
There are a lot of ways to hunt for indications of activity, such as lateral movement, but what needs to happen is that admins need to start looking, even if it means building their list of indicators (and hopefully automating as much of it as makes sense to do...) over time. If you don't know what to look for, ask someone.
If someone were to ask me (this is my opinion, and should not be misconstrued as a statement of my employer's opinion or business model) what was the one thing they could do to increase their odds of detecting malicious behavior, I'd say, "install Sysmon", but that's predicated on someone actually looking at the logs.
Addendum: @Cyborg_DFIR over on Twitter read the original version of this post (prior to the addendum) and felt that I talked more about explaining what you meant instead of talking about it. Fair enough. I don't dispute that. But what I will say is that I, and others, have talked about what to look for. A lot. Does that mean it should stop? No, of course not. Just because something's been talked about before doesn't mean that it doesn't bear repeating or being brought up again.
During July 2013, I wrote 12 articles whose titles started with "HowTo:" and went on to describe what to look for, if you were looking for specific things. More recently, I addressed the topic of detecting lateral movement within the last month.
So, to @Cyborg_DFIR and others who have similar thoughts, questions or comments...I'm more than willing to share what I know, but it's so much easier if you can narrow it down a bit. Is there something specific you're interested in hearing about...or better yet, discussing?
When I went through my initial military training, we spent a lot of time in the outdoors, but during the first 6 months, there was no real "this is what to look for training". It wasn't until a couple of years later, when I returned to be an instructor that the course was teaching new officers the difference between moving through the woods during the day and at night.
Much later, after my military service ended, I got engaged in horseback riding, particularly trail riding. Anyone who's ever done this knows that you become more aware of your surroundings, for a variety of reasons, but most importantly, the safety of your horse, you, and those you may be riding with. You develop an awareness of your surroundings; what's moving near you, and what's further away. Are there runners or walks with dogs (or children in strollers) down the trail? Sometimes you can be warned of the impending approach of others not so much visually, as by what you hear or smell (some riders like to smoke while they're riding). You can tell what is or might be in the area by visual observation (scat, droppings, etc.), as well as listening, and even smell. Why is this important? There's a lot that can spook a horse...horses will smell a carcass well before a human will, and as you ride up, a gaggle of vultures might suddenly take flight. Depending on your horse's temperament, a flock of turkey hens running through a field might spook them or just catch their attention.
If it's recently rained in the area where I'm riding, I'll visually sweep the ground looking for footprints and signs of animals and people. If I see what appear to be fresh impressions of running shoes with dog paw prints near by, I might be looking for a walker or runner with a dog. Most runners have a sense of courtesy to slow down to a walk and may be even say something when approaching horses from the rear. Most...not all. And not everyone who walks a dog really thinks about whether their dog is habituated to horses, or even how the dog will reach when they see horses. I'll also look for signs of deer, because they usually (albeit not always) move in groups. More than once in the springtime, I've come across a fawn coiled up in the tall grass...deer teach their fawns to remain very still, regardless of the circumstances, while they go off to forage. More than once I've seen the fawn well before the fawn has lost its nerve and suddenly bolted from its hiding place.
Now, because of this level of awareness, I had an interesting experience several years ago while hiking with friends at the base of Mount Rainier. At the park entrance, there was a small lake with signs prohibiting fishing, and a sign telling hikers what to do if they spotted a bear. We hiked about 3 1/2 miles to a small meadow with wild blueberries growing. The entire way out and back, there were NO signs of animal life...no insects, no sounds of birds or squirrels. No scat or markings of any kind. The absence of any and all fauna was very extremely evident, and more than a bit odd.
So what?
Okay...so what's my point? If you're familiar with the environment, and aware of your surroundings while performing DFIR work, and know what should be there, you know what to look for, as well as what data sources to go to if you're looking for suspicious activity. It's all about knowing what to hunt for when you're hunting. This is particularly true if you're performing hunting operations in your own environment; however, it can also be applied in cases where you're a consultant (like me), engaging with an unfamiliar infrastructure.
In a recent presentation (BrightTalk, may require registration) at InfoSecurity Europe 2015, Lee Lawson discussed some of the indicators that are very likely available to you right now, particularly if you've done nothing to modify the default audit configuration on Windows systems.
Not long ago, the folks at Rapid7 shared this video, describing four indicators you could use to detect lateral movement within your infrastructure. Unfortunately, two of them are not logged as a result of the default audit configuration of Windows systems, and the presenter doesn't mention alternate Windows Event Log source/ID pairs you can look for instead.
There are a lot of ways to hunt for indications of activity, such as lateral movement, but what needs to happen is that admins need to start looking, even if it means building their list of indicators (and hopefully automating as much of it as makes sense to do...) over time. If you don't know what to look for, ask someone.
If someone were to ask me (this is my opinion, and should not be misconstrued as a statement of my employer's opinion or business model) what was the one thing they could do to increase their odds of detecting malicious behavior, I'd say, "install Sysmon", but that's predicated on someone actually looking at the logs.
Addendum: @Cyborg_DFIR over on Twitter read the original version of this post (prior to the addendum) and felt that I talked more about explaining what you meant instead of talking about it. Fair enough. I don't dispute that. But what I will say is that I, and others, have talked about what to look for. A lot. Does that mean it should stop? No, of course not. Just because something's been talked about before doesn't mean that it doesn't bear repeating or being brought up again.
During July 2013, I wrote 12 articles whose titles started with "HowTo:" and went on to describe what to look for, if you were looking for specific things. More recently, I addressed the topic of detecting lateral movement within the last month.
So, to @Cyborg_DFIR and others who have similar thoughts, questions or comments...I'm more than willing to share what I know, but it's so much easier if you can narrow it down a bit. Is there something specific you're interested in hearing about...or better yet, discussing?
Thursday, June 11, 2015
RegRipper plugin update
I just pushed out an update to the appcompatcache.pl plugin, and committed it to the Github archive. The update was based on a request I'd received to make the output of the tool a bit more manageable, and that was right along the lines of something I'd been thinking about doing for some time, anyway.
In short, the update simply puts the output for each entry on a single line, with the app path and name first, then the date, then other data (that's specific to 32-bit XP, actually), and finally, the executed flag. Each segment is separated by two spaces.
So, what does this mean? Well, the format puts everything on one line, so if you redirect the output to a file and any searches you run will give you the entire line, not just the first line (as with the old format).
Another way to use this new format is the way I like to use it, to determine if there's anything in the ShimCache data that requires my attention:
rip.pl -r d:\cases\local\system -p appcompatcache | find "programdata" /i
Done. That's it. Using DOS commands, it's quick and easy to run through a data sample quickly to see if there's anything of interest.
What techniques do you use during Registry analysis?
In short, the update simply puts the output for each entry on a single line, with the app path and name first, then the date, then other data (that's specific to 32-bit XP, actually), and finally, the executed flag. Each segment is separated by two spaces.
So, what does this mean? Well, the format puts everything on one line, so if you redirect the output to a file and any searches you run will give you the entire line, not just the first line (as with the old format).
Another way to use this new format is the way I like to use it, to determine if there's anything in the ShimCache data that requires my attention:
rip.pl -r d:\cases\local\system -p appcompatcache | find "programdata" /i
Done. That's it. Using DOS commands, it's quick and easy to run through a data sample quickly to see if there's anything of interest.
What techniques do you use during Registry analysis?
Sunday, June 07, 2015
Links
SANS DFIR Poster
If you haven't heard, the new SANS DFIR "Evidence of..." poster is available. I can see looking at the second page of the poster that they've added some items of interest that have been talked about recently. For example, under "Browser Usage", I see mention of Mari's Google Analytics Cookies, and under "Program Execution", I see a reference to the AmCache.hve and the RecentFileCache.bcf files.
What's New in Windows 10
Speaking of "evidence of...", one question I see quite often is, "..what's new in Windows {insert newest version number}?" Some folks at Champlain College have written up a Windows 10 Forensics guide.
The Problem with RegRipper
I was reading herrcore's blog post in which malware that persists via a user's shell extensions, and came across the following statement in the post:
The problem with the two tools I mentioned; RegRipper (shellext.pl plugin) and Autoruns is that they rely on the Shell Extension to be registered using the standard method with HKEY_CLASSES_ROOT.
This quote is taken from the first sentence under a header that says, "A Blind Spot in our Incident Response Tools".
Since I first released RegRipper, my intention was that it would be community-based. That is, that by providing a framework such as RegRipper, the strength of the tool would be not simply that it would be downloaded and blindly pointed at Registry hives, but rather that analysts would either write and contribute their own plugins, or request (providing sample data, as well) plugins be developed. That's right. I totally get that not everyone programs in Perl...which is why I provide Windows executable files for the framework. This is also why if someone doesn't program in Perl but strongly believes that they have a good idea for a plugin, all they need to do is write up a concise description of what it is they'd like to see, and email it to me along with some sample data. When this has happened, I've been able to turn around a functioning plugin pretty quickly...usually within 4 hrs, and often within 1 hr.
This sort of thing has happened before. At the SANS DFIR Summit in 2012, I sat in a presentation, during which the speaker stated, "...RegRipper does not have a plugin for {insert functionality}...". That speaker also stated that RegRipper "does not scale to the enterprise" (which is was NEVER designed to do); however, that speaker had never reached to me to say, "...here's a plugin I wrote...", nor did they ever ask me for such functionality in a plugin. I did find out after the presentation that the presentation had been written several months prior, and that a plugin had been written...the speaker had simply not updated their materials.
I get that there are some roadblocks to having a community-based tool...I completely understand that not everyone programs (nor wants to learn), and that of those who do, not all program in Perl. That's okay. I also understand that a major roadblock for a lot of DFIR analysts is simply...communicating. There are a lot of reasons for this, but the fact is that most DFIR analysts simply do not want to communicate with others within the community.
I would suggest that the real "blindspot" or "problem" isn't whether or not RegRipper (or any other tool) contains specific functionality, but rather, what are we, as analysts, are willing to do to communicate with each other.
That being said, I contacted herrcore, and as a result of an email exchange where he sent me some sample data. I'm researching his findings a little bit more to see if I can modify a current plugin (inprocserver.pl, shellext.pl), or would it make sense to write a new one?
In the meantime, here are some links where I've discussed RegRipper in this blog:
Mar, 2011 - Using RegRipper
Jul, 2012 - Thoughts on RegRipper Support
Aug, 2012 - RegRipper Updates
Addendum, 8 June: This morning, I updated a plugin, and created two others, and committed them to the plugin repository.
inprocserver.pl - I updated this plugin by adding "programdata" to the @alerts list in the alertCheckPath() function, and ran it against the test data that herrcore provided. The result was:
ALERT: inprocserver: programdata found in path: c:\programdata\{9a88e103-a20a-4e
a5-8636-c73b709a5bf8}\ieapfltr.dll
cached.pl - new plugin; run it against the NTUSER.DAT hive to get the values from the \Shell Extensions\Cached key. Running it via rip.exe displays the time value, and the two available CLSID values; I added a simple lookup for the second one. As such, the output appears as follows:
Tue May 26 05:31:59 2015 First Load: {BDFA381D-D8C6-441A-BA17-95EB7FEBEA81} (IDriveFolderExt)
Tue May 26 05:34:57 2015 First Load: {9C73F5E5-7AE7-4E32-A8E8-8D23B85255BF} (IShellFolder)
Tue May 26 05:34:57 2015 First Load: {7007ACC7-3202-11D1-AAD2-00805FC1270E} (IShellFolder)
Tue May 26 05:35:05 2015 First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)
Simple enough. However, if you use your command line fu, you can do something like this:
rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached | find "F6BF"
Launching cached v.20150608
Tue May 26 05:35:05 2015 First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)
cached_tln.pl - new plugin; similar to cached.pl, except that this plugin's output can be added directly to a timeline. Also, this plugin does not have the lookup that cached.pl has...below is an example of the output:
rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached_tln -u keydet89 | find "F6BF"
Launching cached_tln v.20150608
1432618505|REG||keydet89|Cached Shell Ext First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A}
So, there you have it. Typical caveats apply...such as "..these are based on extremely limited test data..", etc.
Also, something I wanted to mention as a result of looking through the hives herrcore sent me was that there were other indicators added to the USRCLASS.DAT hive, as seen in the image to the left. You can see that in addition to the CLSID\{GUID}\InprocServer32 key, another key was added with the path Drive\ShellEx\FolderExtensions\{GUID}.
If you haven't heard, the new SANS DFIR "Evidence of..." poster is available. I can see looking at the second page of the poster that they've added some items of interest that have been talked about recently. For example, under "Browser Usage", I see mention of Mari's Google Analytics Cookies, and under "Program Execution", I see a reference to the AmCache.hve and the RecentFileCache.bcf files.
What's New in Windows 10
Speaking of "evidence of...", one question I see quite often is, "..what's new in Windows {insert newest version number}?" Some folks at Champlain College have written up a Windows 10 Forensics guide.
The Problem with RegRipper
I was reading herrcore's blog post in which malware that persists via a user's shell extensions, and came across the following statement in the post:
The problem with the two tools I mentioned; RegRipper (shellext.pl plugin) and Autoruns is that they rely on the Shell Extension to be registered using the standard method with HKEY_CLASSES_ROOT.
This quote is taken from the first sentence under a header that says, "A Blind Spot in our Incident Response Tools".
Since I first released RegRipper, my intention was that it would be community-based. That is, that by providing a framework such as RegRipper, the strength of the tool would be not simply that it would be downloaded and blindly pointed at Registry hives, but rather that analysts would either write and contribute their own plugins, or request (providing sample data, as well) plugins be developed. That's right. I totally get that not everyone programs in Perl...which is why I provide Windows executable files for the framework. This is also why if someone doesn't program in Perl but strongly believes that they have a good idea for a plugin, all they need to do is write up a concise description of what it is they'd like to see, and email it to me along with some sample data. When this has happened, I've been able to turn around a functioning plugin pretty quickly...usually within 4 hrs, and often within 1 hr.
This sort of thing has happened before. At the SANS DFIR Summit in 2012, I sat in a presentation, during which the speaker stated, "...RegRipper does not have a plugin for {insert functionality}...". That speaker also stated that RegRipper "does not scale to the enterprise" (which is was NEVER designed to do); however, that speaker had never reached to me to say, "...here's a plugin I wrote...", nor did they ever ask me for such functionality in a plugin. I did find out after the presentation that the presentation had been written several months prior, and that a plugin had been written...the speaker had simply not updated their materials.
I get that there are some roadblocks to having a community-based tool...I completely understand that not everyone programs (nor wants to learn), and that of those who do, not all program in Perl. That's okay. I also understand that a major roadblock for a lot of DFIR analysts is simply...communicating. There are a lot of reasons for this, but the fact is that most DFIR analysts simply do not want to communicate with others within the community.
I would suggest that the real "blindspot" or "problem" isn't whether or not RegRipper (or any other tool) contains specific functionality, but rather, what are we, as analysts, are willing to do to communicate with each other.
That being said, I contacted herrcore, and as a result of an email exchange where he sent me some sample data. I'm researching his findings a little bit more to see if I can modify a current plugin (inprocserver.pl, shellext.pl), or would it make sense to write a new one?
In the meantime, here are some links where I've discussed RegRipper in this blog:
Mar, 2011 - Using RegRipper
Jul, 2012 - Thoughts on RegRipper Support
Aug, 2012 - RegRipper Updates
Addendum, 8 June: This morning, I updated a plugin, and created two others, and committed them to the plugin repository.
inprocserver.pl - I updated this plugin by adding "programdata" to the @alerts list in the alertCheckPath() function, and ran it against the test data that herrcore provided. The result was:
ALERT: inprocserver: programdata found in path: c:\programdata\{9a88e103-a20a-4e
a5-8636-c73b709a5bf8}\ieapfltr.dll
cached.pl - new plugin; run it against the NTUSER.DAT hive to get the values from the \Shell Extensions\Cached key. Running it via rip.exe displays the time value, and the two available CLSID values; I added a simple lookup for the second one. As such, the output appears as follows:
Tue May 26 05:31:59 2015 First Load: {BDFA381D-D8C6-441A-BA17-95EB7FEBEA81} (IDriveFolderExt)
Tue May 26 05:34:57 2015 First Load: {9C73F5E5-7AE7-4E32-A8E8-8D23B85255BF} (IShellFolder)
Tue May 26 05:34:57 2015 First Load: {7007ACC7-3202-11D1-AAD2-00805FC1270E} (IShellFolder)
Tue May 26 05:35:05 2015 First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)
Simple enough. However, if you use your command line fu, you can do something like this:
rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached | find "F6BF"
Launching cached v.20150608
Tue May 26 05:35:05 2015 First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A} (IDriveFolderExt)
cached_tln.pl - new plugin; similar to cached.pl, except that this plugin's output can be added directly to a timeline. Also, this plugin does not have the lookup that cached.pl has...below is an example of the output:
rip.pl -r d:\cases\herrcore\ntusertest2.dat -p cached_tln -u keydet89 | find "F6BF"
Launching cached_tln v.20150608
1432618505|REG||keydet89|Cached Shell Ext First Load: {F6BF8414-962C-40FE-90F1-B80A7E72DB9A}
So, there you have it. Typical caveats apply...such as "..these are based on extremely limited test data..", etc.
 |
| USRCLASS.DAT excerpt |
Thursday, May 28, 2015
Detecting Lateral Movement
Almost two years ago, I posted this article that addressed how to track lateral movement within an infrastructure. At the time, I'd been using this information successfully during engagements, and I still use it today.
This morning, I saw this video from Rapid7, and I thought that Mike did a great job with the presentation. Mike made some very good points during his presentation. For example, "SMB" is native to a Windows infrastructure, and with the right credentials, an adversary can go just about anywhere they please.
There were some things missing in the presentation, some caveats that need to be mentioned; I do understand that they were likely left out for the sake of time. However, they are important. For example:
Security-Auditing/4698 events - Scheduled Task creation; under Advanced Security Audit Policy settings, for Object Access, you need to have Audit Other Object Access Events enabled for this event to appear in your Windows Event Logs.
Security-Auditing/4697 events - Service installation; similar to the previous events, systems are not configured to audit for system creation via the Security Event Log by default.
So, the take-away here is that in order for these (and other) events to be useful, what admins need to do is properly configure auditing on systems, as well as employ a SEIM with some sort of filtering capability. Increasing auditing alone will not be useful...I've seen that time and time again when an incident is identified; auditing is ramped up suddenly, and the Security Event Logs start filling up and rolling over in a matter of a few hours, causing valuable information to be lost. The best thing to do is to enable auditing that makes sense within your infrastructure ahead of time, employing the appropriate settings (what to audit, increasing the default size of the Windows Event Log files, etc.) before an incident occurs.
Also, consider the use of MS's Sysmon, sending the collected data to a SEIM (Splunk??). Monitoring process creation (including the command line) is extremely valuable, and not just in incident response. For IR, having the process creation information available (along with a means to monitor it in a timely manner) reduces IR engagements from days or weeks to hours or even minutes. If setting up Sysmon, Splunk, and filters is too daunting a task, consider employing something like Carbon Black.
Thanks to Rapid7 for sharing the video...it's some great information.
Resources
Description of Security Events in Windows 7/Windows Server 2008 R2
This morning, I saw this video from Rapid7, and I thought that Mike did a great job with the presentation. Mike made some very good points during his presentation. For example, "SMB" is native to a Windows infrastructure, and with the right credentials, an adversary can go just about anywhere they please.
There were some things missing in the presentation, some caveats that need to be mentioned; I do understand that they were likely left out for the sake of time. However, they are important. For example:
Security-Auditing/4698 events - Scheduled Task creation; under Advanced Security Audit Policy settings, for Object Access, you need to have Audit Other Object Access Events enabled for this event to appear in your Windows Event Logs.
Security-Auditing/4697 events - Service installation; similar to the previous events, systems are not configured to audit for system creation via the Security Event Log by default.
So, the take-away here is that in order for these (and other) events to be useful, what admins need to do is properly configure auditing on systems, as well as employ a SEIM with some sort of filtering capability. Increasing auditing alone will not be useful...I've seen that time and time again when an incident is identified; auditing is ramped up suddenly, and the Security Event Logs start filling up and rolling over in a matter of a few hours, causing valuable information to be lost. The best thing to do is to enable auditing that makes sense within your infrastructure ahead of time, employing the appropriate settings (what to audit, increasing the default size of the Windows Event Log files, etc.) before an incident occurs.
Also, consider the use of MS's Sysmon, sending the collected data to a SEIM (Splunk??). Monitoring process creation (including the command line) is extremely valuable, and not just in incident response. For IR, having the process creation information available (along with a means to monitor it in a timely manner) reduces IR engagements from days or weeks to hours or even minutes. If setting up Sysmon, Splunk, and filters is too daunting a task, consider employing something like Carbon Black.
Thanks to Rapid7 for sharing the video...it's some great information.
Resources
Description of Security Events in Windows 7/Windows Server 2008 R2
Tuesday, May 26, 2015
Links and Stuff
Registry Goodness
I recently wrote a RegRipper plugin, based on this KB article; on 26 May, I committed it to the plugin repository. I had tweeted to ask the DFIR community if this information was relevant to their investigations, and there was not a great deal of response on the topic...although there was apparently some confusion. I hope that folks take the time to try it, and I hope it's of some use to the DFIR community. I don't often (scratch that...in 15+ years of doing DFIR work, I've never...) need to determine the history of GPOs assigned to a system.
Speaking of RegRipper plugins, Dan posted recently about how he completed the SANS CEIC 2015 Challenge. While he completed the challenge using Eric Zimmerman's Registry Explorer tool, he did state toward the end of the post that he could've used RegRipper to complete the challenge, as well.
From the recent CEIC Conference, you can see David Dym's slides for his Improving Windows External Device Investigations presentation. I know that no matter how many times this subject is addressed and discussed, there will always be confusion as to what resources are available on Windows systems if you are conducting one of these investigations. I think it's great that we've got others talking about this topic, particularly because there seems to be so much confusion in this area. Cory Altheide and I published the initial research into this topic in 2005 (there's a link here), and as new versions of Windows have come out, more information has become available regarding not only which devices were connected to systems, but also which user may have accessed the device.
Speaking of the Registry, Eric Zimmerman recently released a command line tool for interacting with (including searching) a Registry hive file for specific items. Be sure to get version 0.6 of the tool. Eric's been doing a lot of work in creating freeware tools for accessing the Registry, so be sure to check out his other offerings.
AutoStart
Not related to Registry analysis, but TrendMicro recently had a blog post about what they seem to be presenting as a variation in autostarting malware. More than anything else, the post left me more than a little confused...it says that the intruders found an application that was set to run when the system started, and then modified the application's import table by adding a reference to a malicious DLL. It was the next sentence that left me confused:
It is almost impossible to find differences between the original version and the modified ones, as even their file sizes are almost identical.
The post then goes on to say that 4 of the 5 infected applications were discovered as the modified versions weren't signed. However, there still seems to be more going on here, because adding a DLL to the import table of a .exe file, and then referencing the malicious function should make something of an impact on the size of the application, as well as other aspects of the system itself (MFT, USN change journal, etc.).
Processes
Speaking of stuff starting, Corey posted recently regarding some testing he'd done with an MSWord document that would launch an executable.
Something I really like about Corey's post is that there's enough detail in the way he presented the material to not only replicate what he did (if you can or want to get a copy of the file he used...). Also, there's enough information in the post to create things like searches for the pattern after running LogParser against the Sysmon Event Log file, as well as to write Carbon Black watchlist queries.
I recently wrote a RegRipper plugin, based on this KB article; on 26 May, I committed it to the plugin repository. I had tweeted to ask the DFIR community if this information was relevant to their investigations, and there was not a great deal of response on the topic...although there was apparently some confusion. I hope that folks take the time to try it, and I hope it's of some use to the DFIR community. I don't often (scratch that...in 15+ years of doing DFIR work, I've never...) need to determine the history of GPOs assigned to a system.
Speaking of RegRipper plugins, Dan posted recently about how he completed the SANS CEIC 2015 Challenge. While he completed the challenge using Eric Zimmerman's Registry Explorer tool, he did state toward the end of the post that he could've used RegRipper to complete the challenge, as well.
From the recent CEIC Conference, you can see David Dym's slides for his Improving Windows External Device Investigations presentation. I know that no matter how many times this subject is addressed and discussed, there will always be confusion as to what resources are available on Windows systems if you are conducting one of these investigations. I think it's great that we've got others talking about this topic, particularly because there seems to be so much confusion in this area. Cory Altheide and I published the initial research into this topic in 2005 (there's a link here), and as new versions of Windows have come out, more information has become available regarding not only which devices were connected to systems, but also which user may have accessed the device.
Speaking of the Registry, Eric Zimmerman recently released a command line tool for interacting with (including searching) a Registry hive file for specific items. Be sure to get version 0.6 of the tool. Eric's been doing a lot of work in creating freeware tools for accessing the Registry, so be sure to check out his other offerings.
AutoStart
Not related to Registry analysis, but TrendMicro recently had a blog post about what they seem to be presenting as a variation in autostarting malware. More than anything else, the post left me more than a little confused...it says that the intruders found an application that was set to run when the system started, and then modified the application's import table by adding a reference to a malicious DLL. It was the next sentence that left me confused:
It is almost impossible to find differences between the original version and the modified ones, as even their file sizes are almost identical.
The post then goes on to say that 4 of the 5 infected applications were discovered as the modified versions weren't signed. However, there still seems to be more going on here, because adding a DLL to the import table of a .exe file, and then referencing the malicious function should make something of an impact on the size of the application, as well as other aspects of the system itself (MFT, USN change journal, etc.).
Processes
Speaking of stuff starting, Corey posted recently regarding some testing he'd done with an MSWord document that would launch an executable.
Something I really like about Corey's post is that there's enough detail in the way he presented the material to not only replicate what he did (if you can or want to get a copy of the file he used...). Also, there's enough information in the post to create things like searches for the pattern after running LogParser against the Sysmon Event Log file, as well as to write Carbon Black watchlist queries.
Tuesday, May 05, 2015
Stuff
Plugin Updates
Eric Zimmerman reached to me a little while ago and let me know that he'd taken a look at the AppCompatCache data from a Windows 10 system, and found that...wait for it...the format of the data was different from previous versions of Windows. O. M. G.
Thanks to the heads up from Eric, I've updated the RegRipper plugins for parsing this data. However, my testing was extremely limited; I had only one System hive file (from a Windows 10 TP VM that I'd set up) on which to test the parsing code. A dearth of testing data has been an issue since I started writing tools, and it seems that even TaoSecurity has recognized the need for test data.
Interestingly enough, I happened across a System hive file from a Windows 2012 system, and the updates to the parser seemed to work just fine. Again, I said "a" hive...so testing has been extremely limited.
Dumping Passwords
Speaking of the Registry, I ran across this little gem that describes how to dump passwords in plain text from Windows 8.1/2012 systems. I'm a big proponent for finding out what things look like on systems, and it's pretty clear reading through the blog post what an analyst would look for in an acquired image, to determine if something similar to what was described in the post had occurred on the system.
However, I'll put this out there...rather than hoping to find these indicators on a system, why not make IR scoping easier on yourself through the use of process creation monitoring at the endpoints?
Malware Persistence
Here's a good blog post on malware persistence. There's some focus on MS's AutoRuns tool, so it's likely to be familiar to a lot of folks. What I thought was interesting is the number of times we see the Run key being the point of persistence for malware; while many will suggest that this location is 'well known', there are also those of us who see it used time and time again, even when the incident is 'detected' through external, third-party notification. Some may think that the Run key is passe, but hey, it still works, and works well...so why not use it, right?
EVT vs EVTX
Every now and then, I still get an opportunity to analyze Windows XP and 2003 systems...most often, I tend to find myself working with Windows 7 and Windows 2008 R2 systems. Working with older versions of Windows can sometimes necessitate the use of different tools in order to conduct analysis; specifically, when working with the Event Logs, they're in a different location, as well as in a different binary format.
When working with Windows XP and 2003 (and yes, Windows 2000) Event Logs (*.evt files), I'll use evtrpt and evtparse. These tools were written specifically for the binary format of the *.evt files found on Windows 2000, XP, and 2003 systems, and are not intended for use against the *.evtx files found on Vista+ systems.
Evtrpt
This is a tool I wrote a while back to provide me with information about the contents of an EVT file; how many records exist, how many source/ID pairs exist, and what date range do the events cover. What's cool about this tool is that it doesn't use the MS API...which means that it can be run on Linux, and it doesn't rely on the header information of the EVT file to tell it how many records exist.
Evrtp is a command line tool, and takes just one argument...the path to the file you're interested in parsing. If you just type the name of the tool at the command prompt, you'll get a message that says "You must enter a filename". That seems to be pretty straightforward, and adding the full path to the .evt file of interest is all I need to do.
So, I run the tool against an Event Log file that I've extracted from an image, and one of the things I see in the output is the date range for the event records in that file:
Fri Sep 27 17:32:26 2013 to Tue Apr 28 17:37:58 2015
Cool, it covers the time that I'm interested in. Above the date range in the output, I get a list of event sources and IDs, as well as a count of each. For login attempts, the tool also breaks down the login/logoff type. For example, I see the following entry:
Security 538,3 18938
What this tells me is that for the source "Security", there are 18938 events with ID 538 and type 3.
I ran the tool against the other Event Log files from the system, as well. For the Application Event Log, the date range was:
Thu Jan 10 01:52:02 2013 to Tue Apr 28 15:36:04 2015
What I found most interesting from the output of the tool was this entry:
Symantec AntiVirus 51 2
Remember the tool I use for Windows Event Logs, wevtx.bat? The one that uses the eventmap.txt file? Well, in that file, Symantec AntiVirus/51 event records indicate that the product detected malware. Understanding the context of these event source/ID pairs can be extremely valuable, and the evtrpt tool can give you an idea of what pairs are available. For McAfee, I'd look for McLogEvent/257 pairs.
Something of interest from the output of the System Event Log was:
Application Popup 26 11
Application Popup 44 1
So, hopefully by now you can see how useful this tool can be for a quick look at the Event Log files.
Evtparse
This tool operates similar to the evtrpt tool, but the output allows you to see more about the Event Log records. Typing just the name of the tool at the prompt will show you the syntax information, along with example command lines you can use to run the tool. I use this tool to parse through the *.evt file (or files) and add the entries to a timeline of system activity. The command line to launch this tool does not take many arguments, because most of the data that you may want to include in each timeline entry (system name, user name, etc.) is included within each event record.
Why Do I Need The Event Source and the event ID?
Something I see a great deal of within the DFIR community is that Windows Event Log records are referred to only by their ID number. Ok, you're probably wondering...so what? Who cares? Well, it can be important...if someone says that they have mulitple event ID 4100 records, I would have to ask, which source? There are a number of event IDs that have multiple different event sources, each of which can provide completely different context to the situation.
So What?
Why does any of this matter? Context is extremely important when conducting analysis, and in particular when communicating findings to other analysts, as well as to clients. One example was mentioned earlier in this post...the time stamps in the AppCompatCache/ShimCache data is the last modification time of the file, from the file system metadata (the Mandiant white paper is only 5 pages long and is an easy read...).
Another example comes from the output of another RegRipper plugin...the LastWrite time for one of the subkeys from the USBStor key is just that...the key LastWrite time, which is analogous to a file's last modification time. It is NOT the last time that USB device was written to.
So, when communicating findings from the Event Log (or, Windows Event Log on Vista+ systems), providing the event source AND ID can be extremely important for context. If someone just says, "...event ID 4100...", then the very next question should be, "...which event source?" When documenting findings in your case notes, include both the source and ID, as well as a reference, for (possible) inclusion in the eventmap.txt file.
Thanks to the heads up from Eric, I've updated the RegRipper plugins for parsing this data. However, my testing was extremely limited; I had only one System hive file (from a Windows 10 TP VM that I'd set up) on which to test the parsing code. A dearth of testing data has been an issue since I started writing tools, and it seems that even TaoSecurity has recognized the need for test data.
Interestingly enough, I happened across a System hive file from a Windows 2012 system, and the updates to the parser seemed to work just fine. Again, I said "a" hive...so testing has been extremely limited.
AppCompatCache/ShimCache
When working with the AppCompatCache or "ShimCache" data, analysts need to remember the context of the information, and in particular, the time stamps in the data. In most cases, the time stamp is the last modification time for the file in question, from the file system metadata, specifically, the $STANDARD_INFORMATION attribute. It is NOT the date and time that the application was executed.
When working with the AppCompatCache or "ShimCache" data, analysts need to remember the context of the information, and in particular, the time stamps in the data. In most cases, the time stamp is the last modification time for the file in question, from the file system metadata, specifically, the $STANDARD_INFORMATION attribute. It is NOT the date and time that the application was executed.
Dumping Passwords
Speaking of the Registry, I ran across this little gem that describes how to dump passwords in plain text from Windows 8.1/2012 systems. I'm a big proponent for finding out what things look like on systems, and it's pretty clear reading through the blog post what an analyst would look for in an acquired image, to determine if something similar to what was described in the post had occurred on the system.
However, I'll put this out there...rather than hoping to find these indicators on a system, why not make IR scoping easier on yourself through the use of process creation monitoring at the endpoints?
Malware Persistence
Here's a good blog post on malware persistence. There's some focus on MS's AutoRuns tool, so it's likely to be familiar to a lot of folks. What I thought was interesting is the number of times we see the Run key being the point of persistence for malware; while many will suggest that this location is 'well known', there are also those of us who see it used time and time again, even when the incident is 'detected' through external, third-party notification. Some may think that the Run key is passe, but hey, it still works, and works well...so why not use it, right?
EVT vs EVTX
Every now and then, I still get an opportunity to analyze Windows XP and 2003 systems...most often, I tend to find myself working with Windows 7 and Windows 2008 R2 systems. Working with older versions of Windows can sometimes necessitate the use of different tools in order to conduct analysis; specifically, when working with the Event Logs, they're in a different location, as well as in a different binary format.
When working with Windows XP and 2003 (and yes, Windows 2000) Event Logs (*.evt files), I'll use evtrpt and evtparse. These tools were written specifically for the binary format of the *.evt files found on Windows 2000, XP, and 2003 systems, and are not intended for use against the *.evtx files found on Vista+ systems.
Evtrpt
This is a tool I wrote a while back to provide me with information about the contents of an EVT file; how many records exist, how many source/ID pairs exist, and what date range do the events cover. What's cool about this tool is that it doesn't use the MS API...which means that it can be run on Linux, and it doesn't rely on the header information of the EVT file to tell it how many records exist.
Evrtp is a command line tool, and takes just one argument...the path to the file you're interested in parsing. If you just type the name of the tool at the command prompt, you'll get a message that says "You must enter a filename". That seems to be pretty straightforward, and adding the full path to the .evt file of interest is all I need to do.
So, I run the tool against an Event Log file that I've extracted from an image, and one of the things I see in the output is the date range for the event records in that file:
Fri Sep 27 17:32:26 2013 to Tue Apr 28 17:37:58 2015
Cool, it covers the time that I'm interested in. Above the date range in the output, I get a list of event sources and IDs, as well as a count of each. For login attempts, the tool also breaks down the login/logoff type. For example, I see the following entry:
Security 538,3 18938
What this tells me is that for the source "Security", there are 18938 events with ID 538 and type 3.
I ran the tool against the other Event Log files from the system, as well. For the Application Event Log, the date range was:
Thu Jan 10 01:52:02 2013 to Tue Apr 28 15:36:04 2015
What I found most interesting from the output of the tool was this entry:
Symantec AntiVirus 51 2
Remember the tool I use for Windows Event Logs, wevtx.bat? The one that uses the eventmap.txt file? Well, in that file, Symantec AntiVirus/51 event records indicate that the product detected malware. Understanding the context of these event source/ID pairs can be extremely valuable, and the evtrpt tool can give you an idea of what pairs are available. For McAfee, I'd look for McLogEvent/257 pairs.
Something of interest from the output of the System Event Log was:
Application Popup 26 11
Application Popup 44 1
So, hopefully by now you can see how useful this tool can be for a quick look at the Event Log files.
Evtparse
This tool operates similar to the evtrpt tool, but the output allows you to see more about the Event Log records. Typing just the name of the tool at the prompt will show you the syntax information, along with example command lines you can use to run the tool. I use this tool to parse through the *.evt file (or files) and add the entries to a timeline of system activity. The command line to launch this tool does not take many arguments, because most of the data that you may want to include in each timeline entry (system name, user name, etc.) is included within each event record.
Why Do I Need The Event Source and the event ID?
Something I see a great deal of within the DFIR community is that Windows Event Log records are referred to only by their ID number. Ok, you're probably wondering...so what? Who cares? Well, it can be important...if someone says that they have mulitple event ID 4100 records, I would have to ask, which source? There are a number of event IDs that have multiple different event sources, each of which can provide completely different context to the situation.
So What?
Why does any of this matter? Context is extremely important when conducting analysis, and in particular when communicating findings to other analysts, as well as to clients. One example was mentioned earlier in this post...the time stamps in the AppCompatCache/ShimCache data is the last modification time of the file, from the file system metadata (the Mandiant white paper is only 5 pages long and is an easy read...).
Another example comes from the output of another RegRipper plugin...the LastWrite time for one of the subkeys from the USBStor key is just that...the key LastWrite time, which is analogous to a file's last modification time. It is NOT the last time that USB device was written to.
So, when communicating findings from the Event Log (or, Windows Event Log on Vista+ systems), providing the event source AND ID can be extremely important for context. If someone just says, "...event ID 4100...", then the very next question should be, "...which event source?" When documenting findings in your case notes, include both the source and ID, as well as a reference, for (possible) inclusion in the eventmap.txt file.
Sunday, April 26, 2015
Timeline Analysis Process
Having discussed timeline analysis in a couple of blog posts so far (such as here...), I thought I'd take an opportunity to dig a bit deeper into the process I've been using for some time to actually conduct analysis of timelines that I create during engagements.Before we get into the guts of the post, I'd like to start by saying that this is what I've found that works for me, and it does not mean that this is all there is. This is what I've done, and been doing, tweaking the process a bit here and there over the years. I've looked at things like visualization to try to assist in the analysis of time lines, but I have yet to find something that works for me. I've seen how others "do" timeline analysis, and for whatever reason, I keep coming back to this process. However, that does not mean that I'm not open to other thoughts, or discussion of other processes. It's quite the opposite, in fact...I'm always open to discussing ways to improve any analysis process.
Usually when I create a timeline, it's because I have something specific that I'm looking for that can be shown through a timeline; in short, I won't create a timeline (even a micro-timeline) without a reason to do so. It may be a bit of malware, a specific Registry entry or Windows Event Log record, a time frame, etc. As is very often the case, I'll have an indicator, such as web shell file on a system, and find that in some cases, the time frames don't line up between systems, even though the artifact is the same across those systems. It's this information than I can then use, in part, to go beyond the "information" of a particular case, and develop intelligence regarding an adversary's hours of operations, action on objectives, etc.
When creating a timeline, I'll use different tools, depending upon what data I have access to. As I mentioned before, there are times when all I'll have is a Registry hive file, or a couple of Windows Event Logs, usually provided by another analyst, but even with limited data sources, I can still often find data of interest, or of value, to a case. When adding Registry data to a timeline, I'll start with regtime to add key Last Write times from a hive to the timeline. This tool doesn't let me see Registry values, only key Last Write times, but it's value is that it lets me see keys that have been created or modified during a specific time frame, telling me where I need to take a closer look. For example, when I'm looking at a timeline and I see where malware was installed as a Windows service, I'll usually see the creation of the Registry key for the service beneath the Services key (most often beneath both, or all, ControlSets).
When I want to add time stamped information from Registry value data to a timeline, I'll turn to RegRipper and use the plugins that end in *_tln.pl. These plugins (generally speaking) will parse the data from Registry values for the time stamped information, and place it into the necessary format to include it in a timeline. The key aspect to doing this is that the analyst must be aware of the context of the data that they're adding. For example, many analysts seem to believe that the time stamp found in the AppCompatCache (or ShimCache) data is when the program was executed, and in several cases (one announced publicly by the analyst), this misconception has been passed along to the customer.
I also use several tools that let me add just a few events...or even just one event...to the time line. For example, the RegRipper secrets_tln.pl plugin lets me add the Last Write time of the Policy/Secrets key from the Security hive to the timeline. I can check the time stamp first with the secrets.pl plugin to see if it's relevant to the time frame I'm investigating, and if it is, add it to the timeline. After all, why add something to the timeline that's not relevant to what I'm investigating?
When creating a timeline, I start with the events file (usually, events.txt), and use parse.exe to create a full timeline, or a partial timeline based on a specific date range. So, after running parse.exe, I have the events.txt file that contains all of the events that I've extracted from different data sources using different tools (whichever applies at the time), and I have either full timeline (tln.txt) or a shortened version based on a specific date range...or both. To begin analysis, I'll usually open the timeline file in Notepad++, which I prefer to use because it allows me to search for various things, going up or down in the file, or it can give me a total count of how many times a specific search term appears in the file.
Once I begin my analysis, I'll open another tab in Notepad++, and call it "notes.txt". This is where all of my analysis notes go while I'm doing timeline analysis. As I start finding indicators within the timeline, I'll copy-and-paste them out of the timeline file (tln.txt) and into the notes file, keeping everything in the proper sequence.
Timeline analysis has been described as being an iterative process, often performed in "layers". The first time going through the timeline, I'll usually find a bunch of stuff that requires my attention. Some stuff will clearly be what I'm looking for, other stuff will be, "...hey, what is this..."...but most of what's in the timeline will have little to do with the goals of my exam. I'm usually not interested in things like software and application updates, etc., so having the notes file available lets me see what I need to see. Also, I can easily revisit something in the timeline by copying the date from the notes file, and doing a search in the timeline...this will take me right to that date in the timeline.
Recently while doing some timeline analysis, I pulled a series of indicators out of the timeline, and pasted them into the notes file. Once I'd followed that thread, I determined that what I was seeing as adware being installed. The user actively used the browser, and the events were far enough back in time that I wasn't able to correlate the adware installation with the site(s) that the user had visited, but I was able to complete that line of analysis, note what I'd found, remove the entries from the notes file, and move on.
As timeline analysis continues, I very often keep the data source(s) open and available, along with the timeline, as I may want to see something specific, such as the contents of a file, or the values beneath a Registry key. Let's say that the timeline shows that during a specific time frame that I'm interested in, the Last Write time of the HKLM/../Run key was modified; I can take a look at the contents, and add any notes I may have ("...there is only a single value named 'blah'...") to the notes file.
Many times, I will have to do research online regarding some of the entries in the timeline. Most often, this will have to do with Windows Event Log entries; I need to develop an understanding of what the source/ID pair refers to, so that I can fill in the strings extracted from the record and develop context around the event itself. Sometimes I will find Microsoft-Windows-Security-Auditing/5156 events that contain specific process names or IP addresses of interest. Many times, Windows Event Log record source/ID pairs that are of interest will get added to my eventmap.txt file with an appropriate tag, so that I have additional indicators that automatically get identified on future cases.
Not everything extracted from the timeline is going to be applicable to the goals of my analysis. I've pulled data from a timeline and my research has determined that the events in question were adware being installed. At that point, I can remove the data from my notes file.
By the time I've completed my timeline analysis, I have the events file (all of the original events), the timeline file, and the notes file. The notes file is where I'll have the real guts of my analysis, and from where I'll pull things such as indicator clusters (several events that, when they appear together, provide context and a greater level of confidence in the data...) that I've validated from previous engagements, and will use in future engagements, as well as intel I can use in conjunction with other analysis (other systems, etc.) to develop a detailed picture of activity within the enterprise.
Again, this is just the process I use and have found effective...this is not to say that this is what will work for everyone. And I have tried other processes. I've had analysts send me automatically-created colorized spreadsheets and to be honest, I've never been very clear as to what they've found or thought to be the issue. That is not to say that this method of analysis isn't effective for some, as I'm sure it is...I simply don't find it effective. The process I described has been effective for me at a number of levels...from having a single data source from a system (i.e., a single Registry hive...), to having an entire image, to analyzing a number of systems from the same infrastructure. And again, I'm not completely stuck to this process...I'm very open to discussion of other processes, and if I do find something that proves to be effective, I have no problem adding it to what I do, or even changing my process all together.
Sunday, April 19, 2015
Micro- & Mini-Timelines
Mini, micro, and even nano-timelines can assist an analyst in answering questions and addressing analysis goals in an extremely timely and accurate manner.
There are times where I will have a full image of a system, and only create a mini- or nano-timeline, just to see if there are specific indicators or artifacts available within the image. This helps me triage systems and prioritize my analysis based upon the goals that I've been given or developed. For example, if the question before me is to determine if someone accessed a system via RDP, I really only need a very limited number of data sources to answer that question, or even just to determine if it can be answered. I was once asked to determine the answer to that question for a Windows XP system, and all I needed was the System Registry hive file...I was able to show that Terminal Services was not enabled on the system, and it hadn't been. Again, the question I was asked (my analysis goal) was, "...did someone use RDP to access this system remotely?", and I was able to provide the answer to that question (or perhaps more specifically, if that question could be answered).
Sometimes, I will create a micro-timeline from from specific data sources simply to see if there are indicators that pertain to the time frame that I've been asked to investigate. One example that comes to mind is the USN change journal...I'll extract the file from an image and parse it, first to see if it covers the time frame I'm interested in. From there, I will either extract specific events from that output to add to my overall timeline, or I'll just add all of the data to the events file so that it's included in the timeline. There are times when I won't want all of the data, as having too much of it can add a significant amount of noise to the timeline, drowning out the signal.
There are times when I simply don't need all of the available data. For example, consider a repurposed laptop (provided to an employee, later provided to another employee), or a system with a number (15, 25, or more) of user profiles; there are times that I don't need information from every user profile on the system, and including it in the timeline will simply make the file larger and more cumbersome to open and analyze.
I've also created what I refer to as nano-timelines. That is, I'll parse a single Windows Event Log (.evtx) file, filter it for a specific event source/ID pair, and then create a timeline from just those events so that I can determine if there's something there I can use.
For example, let's say I'm interested in "Microsoft-Windows-Security-Auditing/5156" events; I'd start by running the Security.evtx file through wevtx.bat:
C:\tools>wevtx.bat F:\data\evtx\security.evtx F:\data\sec_events.txt
Now that I have the events from the Security Event Log in a text file, I can parse out just the events I'm interested in:
C:\tools>type F:\data\sec_events.txt | find "Microsoft-Windows-Security-Auditing/5156" > F:\data\sec_5156_events.txt
Okay, now I have an events file that contains just the event records I'm interested in; time to create the timeline:
C:\tools>parse -f F:\data\sec_5156_events.txt > F:\data\sec_5156_tln.txt
Now, I can open the timeline file, see the date range that those specific events cover, as well as determine which events occurred at a specific time. This particular event can help me find indications of malware (RAT, Trojan, etc.), and I can search the timeline for a specific time frame, correlating outbound connections from the system with firewall or IDS logs. Because I still have the events file, I can write a quick script that will parse the contents of the events file, and provide me statistics based on specific fields, such as the destination IP addresses of the connections.
What's great about the above process is that an analyst working on an engagement can archive the Windows Event Log file in question, send it to me, and I can turn around an answer in a matter of minutes. Working in parallel, I can assist an analyst who is neck-deep in an IR engagement by providing solid answers to concrete questions, and do so in a timely manner. My point is that we don't always need a full system image to answer some very important questions during an engagement; sometimes, a well-stated or well-thought-out question can be used as an analysis goal, which leads to a very specific set of data sources within a system being examined, and the answer to whether that system is in scope or not being determined very quickly.
Analysis Process
Regardless of the size of the timeline (full-, mini-, micro-), the process I follow during timeline analysis is best described as iterative. I'll use initial indicators...time stamps, file names/paths, specific Registry keys...to determine where to start. From there, I'll search "nearby" within the timeline, and look for other indicators.
I mentioned the tool wevtx.bat earlier in this post; something I really like about that tool is that it helps provide me with indicators to search for during analysis. It does this by mapping various event records to tags that are easy to understand, remember, and search for. It does this through the use of the eventmap.txt file, which is nothing more than a simple text file that provides mappings of events to tags. I won't go into detail in this blog post, as the file can be opened in viewed in Notepad. What I like to do is provide references as to how the tag was "developed"; that is, how did I decide upon the particular tag. For example, how did I decide that a Microsoft-Windows-TerminalServices-LocalSessionManager record with event ID 22 should get the tag "Shell Start"? I found it here.
This is very useful, because my timeline now has tags for various events, and I know what to look for, rather than having to memorize a bunch of event sources and IDs...which, with the advent of Vista and moving into the Window 7 system and beyond, has become even more arduous due to the shear number of Event Logs now incorporated into the systems.
So, essentially, eventmap.txt serves as a list of indicators, which I can use to search a timeline, based upon the goals of my exam. For example, if I'm interested in locating indications of a remote access Trojan (RAT), I might search for the "[MalDetect]" tag to see if an anti-virus application on the system picked up early attempts to install malware of some kind (I should note that this has been pretty helpful for me).
Once I find something related to the goals of my exam, I can then search "nearby" in the timeline, and possibly develop additional indicators. I might be looking for indications of a RAT, and while tracking that down, find that the infection vector was via lateral movement (Scheduled Task). From there, I'd look for at least one Security-Auditing/4624 type 3 event, indicating a network-based logon to access resources on the system, as this would help me determine the source system of the lateral movement. The great thing about this is that this sort of activity can be determined from just three Windows Event Log files, two Registry hives, and you can even throw in the MFT for good measure, although it's not absolutely required. Depending on the time frame of response...that is, was the malicious event detected and the system responded to in a relatively short time (an hour or two), or is this the result of a victim notification of something that happened months ago...I may include the USN change journal contents, as well.
My efforts are most often dedicated toward finding clusters of multiple indicators of specific activity, as this provides not only more context, but also a greater level of confidence in the information I'm presenting. Understanding the content of these indicator clusters is extremely helpful, particularly when anti-forensics actions have been employed, however unknowingly. Windows Event Logs may have "rolled over", or a malware installer package may include the functionality to "time stomp" the malware files.
Friday, April 10, 2015
Talk Notes
Thanks to Corey Harrell, I was watching the Intro to Large Scale Detection Hunting presentation from the NoLaSec meeting in Dec, 2014, and I started to have some thoughts about what was being said. I looked at the comments field on YouTube, as well as on David's blog, but thought I would put my comments here instead, as it would give me an opportunity to structure them and build them out a bit before hitting the "send" button.First off, let me say that I thought the talk was really good. I get that it was an intro talk, and that it wasn't going to cover anything in any particular depth or detail. I liked it enough that I not only listened to it beginning-to-end twice this morning, but I also went back to certain things to re-listen to what was said.
Second, the thoughts I'm going to be sharing here are based on my perspective as an incident responder and host/endpoint analyst.
Finally, please do not assume that I am speaking for my employer. My thoughts are my own and not to be misconstrued as being the policies or position of my employer.
Okay, so, going into this, here are some comments and thoughts based on what I saw/heard in the presentation...
Attribution...does it matter?
As David said, if you're gov, yeah (maybe). If you're a mom-and-pop, not so much. I would suggest that during both hunting and IR, attribution can be a distraction. Why is that?
Let's look at it this way...what does attribution give us? What does it tell us? Some say that it informs as to the intent of the adversary, and that it tells us what they're after. Really? Many times, an organization that has been compromised doesn't fully understand that they have that's "of value". Is it data of some kind? Marketing materials? Database contents? Manufacturing specs? Or, is it the access that organization has to another organization? If you're doing some hunting, and run across an artifact or indicator that puts you on high alert, how are you able to perform attribution?
Let's say that you find a system with a bunch of batch files on it, and it looks as if the intruder was performing recon, and even dumping credentials from systems...at this point, how do you perform attribution? How do you determine intent?
"If you can identify TTPs, you can..."
...but how do you identify TTPs? David talked about identifying TTPs and disrupting those, to frustrate the adversary; examples of TTPs were glossed over, but I get that, it's an intro talk. This goes back to what does something "look like"...what does a TTP "look like"?
I'm not saying that David missed anything by glossing over this...not at all. I know that there was a time limit to the talk, and that you can only cover so much in a limited time.
Can't automate everything...
No, you can't. But there's much that you can automate. Look at your process in a Deming-esque manner, and maybe even look at ways to improve your process, using automation.
"Can't always rely on signatures..."
That really kind of depends on the "signatures" used. For example, if you're using "signatures" in the sense that AV uses signatures, then no, you can't rely on them. However, if you're aware that signatures can be obviated and MD5 hashes can be changed very quickly, maybe you can look at things that may not change that often...such as the persistence mechanism. Remember Conficker? MS identified five different variants, but what was consistent across them was the persistence mechanism.
This is a great time to mention artifact categories, which will ultimately lead to the use of an analysis matrix (the link is to a 2 yr old blog post that was fav'd on Twitter this morning...)...all of which can help folks with their hunting. If you understand what you're looking for...say, you're looking for indications of lateral movement...you can scope your hunt to what data you need to access, and what you need to look for within that data.
It's all about pivoting...
Yes, it is.
...cross-section of behaviors for higher fidelity indicators...
Pivoting and identifying a cross-section of behaviors can be used together in order to build higher fidelity indicators. Something else that can be used is to do the same thing is...wait for it...sharing. I know that this is a drum that I beat that a lot of folks are very likely tired of hearing, but a great way of creating higher fidelity indicators is to share what we've seen, let others use it (and there's no point in sharing of others don't use it...), and then validate and extend those indicators.
David also mentioned the tools that we (hunters, responders) use, or can put to use, and that they don't have to be big, expensive frameworks. While I was working in an FTE security engineer position a number of years ago, I wrote a Perl script that would get a list of systems active in the domain, and then reach out to each one and dump the contents of the Run key from the Registry, for both the system and the logged on user. Over time, I built out a white list of known good entries, and ended up with a tool I could run when I went to lunch, or I could set up a scheduled task to have it run at night (the organization had shifts for fulfillment, and 24 hr ops). Either way, I'd come back to a very short list (half a page, maybe) of entries that needed to be investigated. This also let me know which systems were recurring...which ones I'd clean off and would end up "infected" all over again in a day or two, and we came up with ways to address these issues.
So, my point is that, as David said, if you know your network and you know your data sources, it's not that hard to put together an effective hunting program.
At one point, David mentioned, "...any tool that facilitates lateral movement...", but what I noticed in the recorded presentation was that there were no questions about what those tools might be, or what lateral movement might look like in the available data.
Once we start looking at these questions and their responses, the next step is to ask, do I have the data I need? If you're looking at logs, do you have the right logs in order to see lateral movement? If you have the right sources, are they being populated appropriately? Is the appropriate auditing configured on the system that's doing the logging? Do you need to add additional sources in order to get the visibility you need?
"Context is King!"
Yes, yes it is. Context is everything.
"Fidelity of intel has to be sound"
Intel is worthless if it's built on assumption, and you obviate the need for assumption by correlating logs with network and host (memory, disk) indicators.
"Intel is context applied to your data"
Finally, a couple of other things David talked about toward the end of the presentation were with respect to post-mortem lessons learned (and feedback loops), and that tribal knowledge must be shared. Both of these are critical. Why?
I guess that another way to ask that question is, is it really "cost effective" for every one of us to have to all learn the same lessons on our own? Think about how "expensive" that is...you may see something and even if I were hunting in the same environment, I may not see that specific combination of events for the next 6 months or a year, if ever. Or, I may see it, but not recognize it as something that needs to be examined.
Sharing tribal knowledge can also mean sharing what you've seen, even though others may have already "seen" the same thing, for two reasons: (1) it validates the original finding, and (2) it lets others know that what they saw 6 months ago is still in use.
Consider this...I've seen many (and I do mean, MANY) malware analysts simply ignore the persistence mechanism employed by malware. When asked, some will say, "...yeah, I didn't say anything because it was the Run key...". Whoa, wait a second...you didn't think that was important? Here it is 2015, and the bad guys are still using the Run key for persistence? That's HUGE! That not only tells us where to look, but it also tells us that many of the organizations that have been compromised could have detected the intrusion much sooner with even the most rudimentary instrumentation and visibility.
Dismissing the malware persistence mechanism (or any other indicator) in this way blinds the rest of the hunting team (and ultimately, the community) to it's value and efficacy in the overall effort.
Summary
Again, this was a very good presentation, and I think serves very well to open up further conversation. There's only so much one can talk about in 26 minutes, and I think that the talk was well organized. What needs to happen now is that people who see the presentation start implementing what was said (if they agree with it), or asking how they could implement it.
Resources
Danny's blog - Theoretical Concerns
David Bianco's blog - Pyramid of Pain
Andrew Case's Talk - The Need for Proactive Threat Hunting (slides)
Monday, April 06, 2015
Blogging
I caught an interesting thread on Twitter last week..."interesting" in the sense that it revisited one of the questions I see (or hear) quite a bit in DFIR circles; that is, how does one get started in the DFIR community? The salient points of this thread covered blogging (writing, in general) and interacting within the community. Blogging is a great way for anyone, regardless of how long you've been "doing" DFIR, to engage and interact with the community at large.Writing
Writing isn't easy. I get it. I'm as much a nerd as anyone reading this blog, and I feel the same way most of you do about writing. However, given my storied background, I have quite a bit of experience writing. Even though I was an engineering major in college, I had to take writing classes. One of my English professors asked if I was an English major, saying that I wrote like one...while handing back an assignment with a C (or D) on it. I had to write in the military....fitreps, jagmans, etc. I had jobs in the military that required other kinds of writing, for different audiences.
Suffice to say, I have some experience. But that doesn't make me an expert, or even good at it. What I've found is that the needs of the assignment, audience, etc., vary and change.
So how do you get better at writing? Well, the first step is to read. Seriously. I read a lot, and a lot of different things. I read the Bible, I read science fiction, and I read a lot of first person accounts from folks in special ops (great reading while traveling). Some of the stuff I've read recently has included:
The Finishing School (Dick Couch) - I've read almost all of the books Mr. Couch as published
Computer Forensics: InfoSec Pro Guide (David Cowen)
Do Androids Dream of Electric Sheep (Philip K. Dick)
I've also read Lone Survivor, American Sniper, and almost every book written by William Gibson.
Another way to get better at writing is to write. Yep, you read that right. Write. Practice writing. A great way to do that is to open MSWord or Notepad, write something and hand it to someone. If they say, "....looks good..." and hand it back, give it to someone else. Get critiqued. Have someone you trust read what you write. If you're writing about something you did, have the person reading it follow what you wrote and see if they can arrive at the same end point. A couple of years ago, I was working with some folks who were trying write a visual timeline analysis tool, and to get started, the first thing the developer did was sit down with my book and walk through the chapter on timelines. He downloaded the image and tools, and walked through the entire process. He did this all on his own accord and initiative, and produced EXACTLY what I had developed. That was pretty validating for my writing, that someone with no experience in the industry could sit down and just read, and the process was clear enough that he was able to produce exactly what was expected.
Try creating a blog. Write something. Share it. Take comments...ignore the anonymous comments, and don't worry if someone is overly critical. You can ignore them, too.
My point is, get critiqued. You don't sharpen a knife by letting it sit, or rubbing it against cotton. The way to get better as a writer, and as an analyst, is to expose yourself to review. The cool thing about a blog is that you can organize your thoughts, and you can actually have thoughts that consist of more than 140 characters. And you don't have to publish the first thing you write. At any given time, I usually have half a dozen or more draft blog posts...before starting this post, I deleted two drafts, as they were no longer relevant or of interest.
Writing allows you to organize your thoughts. When I was writing fitness reports for my Marines, I started them days (in some cases, weeks) prior to the due date. I started by writing down everything I had regarding that Marine, and then I moved it around on paper. What was important? What was truly relevant? What needed to be emphasized more, or less? What did I need to take out completely? I'd then let it sit for a couple of days, and then come back to it with a fresh set of eyes. Fitreps are important, as they can determine if a Marine is promoted or able to re-enlist. Or they can end a career. Also, they're critiqued. As a 22 yr old 2ndLt, I had Majors and Colonels reviewing what I wrote, and that was just within my unit. Getting feedback, and learning to provide constructive feedback, and go a long way toward making you a better writer.
I included a great deal of my experiences writing reports in chapter 9 of Windows Forensic Analysis Toolkit 4/e, and included an example scenario (associated with an image), case notes and report in the book materials. So, if you're interested, download the materials and take a look.
One of the tweets from the thread:
it's a large sea of DFIR blogs and could be very intimidating to newbies in the field. What can they offer that is not there
Let's break this down a bit. Yes, there are a lot of DFIR blogs out there, but as Corey tweeted, The majority of the DFIR blogs in my feed are either not active or do a few posts a year. The same is true in my feed (and I suspect others will see something similar)...there are a number of blogs I subscribe to that haven't been updated in months or even a year or more (Grayson hasn't updated his blog in over two years). There are several blogs that I've removed, either because they're completely inactive, or about ever 6 months or so, there's a "I know I haven't blogged in a while..." post, but nothing more.
There's no set formula for blog writing. There are some blogs out there that have a couple of posts a month, and don't really say anything. Then there are blogs like Mari's...she doesn't blog very much, but when she does, it's usually pure gold. Corey's blog is a great example of how there's always something that you can write about.
...but I'm a n00b...
The second part of the above tweet is something I've seen many times over the years...folks new to the community say that they don't share thoughts or opinions (or anything else) because they're too new to offer anything of value.
That's an excuse.
A couple of years ago, one of the best experiences in my DFIR career was working with Don Weber. I had finished up my time in the military as a Captain, and Don had been a Sgt. On an engagement that we worked together, he was asking me why we were doing certain things, or why we were doing things a certain way. Don wasn't completely new to the DFIR business, but he was new to the team, and he had fresh perspective to offer. Also, his questions got me to thinking...am I doing this because there's a good reason to do so, or am I doing it because that's the way I've always done it?
One of the things that the "...I'm a n00b and have nothing to offer..." leads to is a lack of validation within the community. What do I mean by that? Well, there's not one of us in the field who's seen everything that there is to see. Some folks are new to the field and don't have the experience to know where to look, or to recognize what they're seeing. Others have been in the field so long that they no longer see what's going on "in the weeds"; instead, all they have access to is an overview of the incident, and maybe a few interesting tidbits. Consider the Poweliks malware; I haven't had an investigation involving this malware, but I know folks who have. My exposure to it has been primarily through AV write-ups, and if someone hadn't shared it with me, I never would've known that it uses other Registry keys for persistence, including CLSID keys, as well as Windows services. My point is that someone new the community can read about a particular malware variant, and then after an exam, say, "...I found these four IOCs that you described, and this fifth one that wasn't in any of the write-ups I read...", and that is a HUGE contribution to the community.
Even simply sharing that you've seen the same thing can be validating. "Yes, I saw that, as well..." lets others know that the IOC they found is being seen by others, and is valid. When I read the Art of Memory Forensics, and read about the indicator for the use of a credential theft tool, I could have left it at that. Instead, I created a RegRipper plugin and looked for that indicator on cases I worked, and found a great deal of validation for the indicator...and I shared that with one of the book authors. "Yes, I'm seeing that, as well..." is validating, and "...and I'm also seeing this other indicator..." serves to move the community forward.
If you're not seeing blog posts about stuff that you are interested in, reach out and ask someone. Sitting behind your laptop and wondering, "...why doesn't anyone post about their analysis process?" doesn't inherently lend itself to people posting about their analysis process. Corey's post about his process, I've done it, Mari's done it...if this is something you like to see, reach out to someone and ask them, "hey, could you post your thoughts/process regarding X?"
Not seeing content that you're interested in in the blogs you follow? Start your own blog. Reach out to the authors of the blogs you follow, and either comment on their blogs or email them directly, and share your thoughts. Be willing to refine or elaborate on your thoughts, offering clarity. If you are interested in how someone would perform a specific analysis task, be willing to offer up and share data. It doesn't matter how new you are to the industry, or if you've been in the industry for 15 years...there's always something new that can be shared, whether it's data, or even just a perspective.
Blogging is a great way to organize your thoughts, provide context, and to practice writing. Who knows, you may also end up learning something in the long run. I know I have.
Sunday, March 15, 2015
Perspectives on Threat Intel
 |
| Source: detect-respond.blogspot.com |
Thinking about it, I can see where both are true.
To begin with, let's consider this "order of volatility"...what am I referring to? Essentially, what I'm talking about was detailed in 2002, in RFC 3227, Guidelines for Evidence Collection and Archiving. In short, the RFC states that when collecting evidence, "you should proceed from volatile to the less volatile". What this means is that when collecting "evidence", you should collect that evidence that is most likely to change first, or soonest. This is a guiding principle that should be used to direct collection methodologies.
As such, the "order of volatility" itself is guidance, as the definition appears in section 2.1 of the RFC, whereas the discussion of actual collection does not begin until section 3.
The term "shelf life" refers to the fact that threat intel indicators have a time period during which they are useful, or have value. Notice that I don't say "specified time period", because that can vary. Those who conduct these types of investigations have seen where a single file, with the same name and stored in the same file system location on two different endpoints, placed in those locations minutes apart, may have different hashes. Or, during an IR investigation, you may find RATs on two different endpoints that are essentially the same version, but with different C2 domain names. When doing historical analysis of indicators such as collected hashes and domain names, we see how these are useful for a limited amounted of time; they have a "shelf life".
Several years ago when I was doing PCI investigations, we ran across a file named "bp0.exe". We'd seen it before, and happened to have a copy of the file that we'd seen 8 months prior to the current investigation. Both files have the same path within the file system (on two completely different investigations and endpoints, of course), and they had different MD5 hashes. Using fuzzy hashing, we found that they were 98% similar (using the phraseology somewhat loosely). This is a good example of how MD5 hashes have a "shelf life" and tend to remain valid for a limited time.
When you consider David Bianco's Pyramid of Pain from a network- or malware RE-perspective, the technical indicators at the lower half of the pyramid (hash values, C2 IP addresses, domain names) definitely have a shelf life; they are only 'good' (valid) for a specified period of time. These indicators can change between campaigns, or as is often the case, during a campaign. Those who perform threat intel collection and analysis are also aware that C2 IP addresses and domain names can also change quickly (often within hours or even minutes), and there are organizations that continually monitor this sort of thing and track them (i.e., what IP addresses various domain names resolve to, etc.) over time.
So, when you look at "threat intel" from a perspective that is external to a compromised infrastructure, using open source intel collection (and including analysis of samples from sites such as VirusTotal...), then the indicators do, indeed, have a shelf life.
However, when considering these same threat intel indicators from the perspective of the endpoint systems, we can see how they have an order of volatility, as well, and that delays in detection and response will lead to some of these endpoint indicators becoming more difficult to recover, and even unavailable. If an installer is run on a system, and deletes itself after infecting the endpoint, then the file (along with the MD5 hash of that file) is gone. In some cases, this happens so quickly that the installer file itself may not be written to physical disk, so there is literally nothing that can be recovered, or "carved". When malware reports out to a C2 domain, how long does that persist on the endpoint? Well, it may depend on the particular API used by the malware to perform that off-system communications. If the malware was written to create it's own network sockets, the domain name may exist in memory for only a very short time, and persist on the network (this does not include any logs on other endpoints) for an even shorter period of time. The domain name may be found in the pagefile, but again, this does not mean that the domain name is recorded on the endpoint indefinitely...even a C2 domain name or URL will only persist in the pagefile for so long.
If you consider the Pyramid of Pain from the perspective of endpoints on a compromised infrastructure, the indicators begin to have an "order of volatility", in the manner described in RFC 3227, Some indicators can persist for varying periods of time on those endpoints; some will persist for only a short time, while others will persist for quite some time.
For example, some indicators may be present in the Security Event Log, and in most cases (that I've dealt with), event records of value have been obviated by the normal operation of the system, simply due to the fact that the Security Event Logs have "rolled over", as older event records have been overwritten by newer ones. I've received images of systems and the Security Event Log was 22MB in size, and when parsed, contained maybe...maybe...2 days worth of events. The specific event I was interested in occurred weeks (or in some cases, months) prior to when the image as acquired.
Some data sources...RecentFileCache.bcf file, AppCompatCache data, Prefetch files, for example...can be obviated by the passage of time and the normal operation of the system. I've seen IR team response procedures that included running multiple tools on a live system, which caused the Prefetch files of interest to be deleted, as new programs were run and new Prefetch files created by the operating system.
Ultimately, it seems that the discussion of "shelf life" versus "order of volatility" depends upon your perspective. If you're not considering endpoints at all, and only looking at the "threat intel" that we usually see collected, discussed and shared (MD5 hashes, C2 IP address and domains) through open sources, then yes, I believe that it is well understood that the indicators do have a "shelf life"; that is, a C2 IP address or domain may be valid at the time that it was found, but there's nothing to say that it will continue to be valid 6 weeks or 6 months later.
However, from the perspective of the endpoint, it's pretty clear that indicators have an order of volatility all their own, and that order can be impacted (in some cases, significantly) by external stimulus, such as IR data collection procedures, or actions taken by an adversary (or an admin).
Full Disclosure
Like many other organizations, my employer provides threat intelligence to clients, some of which is network- and malware-based, and collected through open sources. In my role within the company, as an incident responder and digital forensic analyst, I tend to be both a consumer and producer of threat intel that is based on analysis of endpoints. What I wanted to point out in this post is that there are different perspectives on the issue, and that doesn't mean that any one is wrong.
Addendum, 17 Mar: Looking back on this post, it occurs to me that the "shelf life" description applies to indicators in the bottom half of the pyramid, from a malware RE perspective, and the "order of volatility" description applies to indicators at all levels of the pyramid, from a host or endpoint perspective.
Tuesday, March 10, 2015
Links
Revisiting Macros
Kahu Security posted this recent blog article that was pretty interesting. I thought that the trick that was used was pretty interesting, and yes, "sneaky"...but part of me was wondering what this sort of thing would "look like" within a system image. What I mean is, if you're tasked with looking at an image of a system that may have been infected via this sort of trick, what would you look for?
The first thing that jumps out at me is the warning displayed in Word, in the second figure in the post. Once the user clicks on the "Enable Content" button, a record is created within the user's MSOffice TrustRecords key. This information can be extract using the RegRipper trustrecords.pl plugin, or added to a timeline using the trustrecords_tln.pl plugin. These plugins were mentioned as part of the HowTo: Determine User Access to Files blog post from July, 2013.
Once the user clicks on the button and the macros are enabled, you'll see the other files described in the blog post created and launched within the file system. Because the command execution does not persist in memory once the process completes, this is an excellent argument for the use of tools such as Sysmon and Carbon Black.
If some of the files that are part of the infection process are deleted or time stomped, AND you can get to the system relatively quickly, a great resource for analysis is the USN change journal.
As far as recovering/extracting the actual macro itself, take a look at this blog post for some helpful hints and tools. Also, the folks at OpenDNS posted about Investigating a Malicious Attachment without Reversing.
USN Change Journal
Speaking of files being created on a system (see what I did there?), Mari has a new blog post up where she shares her experience using the USN change journal during analysis. As you can see in her excellent blog post, the USN change journal remains an excellent resource for obtaining extremely transitory information regarding system activity; while we don't know exactly which process is responsible for various files being created, we can see within a timeline when the various file system activities occurred, and this can not only provide additional context to a timeline, but it can also fill in some gaps in that timeline.
It's great that Mari is sharing her analysis experience with others, as it really helps those of us who may not have the same types of cases as she does, or those who may not approach (or "do") analysis in the same way. It's the sharing of those experiences, as well as asking questions, that builds a stronger community.
ADSs
I ran across Matt's recent blog post...what attracted my attention to it were the references ADSs and Powershell. ADSs are something I've been interested in for quite a long time, and I've included sections in my books that have discussed creating them, running code from within them, and what they "look like" to tools such as Carbon Black.
As to the post, there was an exchange on Twitter regarding the original content of the post, which centered around the use of the phrase "without touching disk"...Matt took the initiative to correct this, as you cannot create an ADS, and at the same time say that you aren't "touching disk". This is an interesting approach, and Matt's right...under most normal circumstances, at least the circumstances I encounter as an incident responder, something like this would go undetected by sysadmins. However, this is pretty trivial to address for an incident responder, using various artifacts, some that don't hang around as long (see this blog post), and others that persist for a while longer.
Registry Stuff
I recently ran across this post over on the System Forensics blog...unfortunately, as is the case with many blogs (it seems), comments are turned off, so I have to comment here...
Early on in the post, Patrick says:
Then I ran a few more well known tools and in one case didn’t see some of the entries at all, and in another case saw the entries, but no context was provided.
Interesting...which tools? Was anything done to contact the author(s)? Was any data shared so that the author(s) could make the appropriate updates?
At the end of the post, Patrick says:
If you’re simply relying on the output of a tool you’re possibly missing some good information.
He's absolutely right, which is why I strongly recommend that analysts get into the Registry when performing analysis, looking to see what's there. This is particularly true if there are any issues with tools that don't show you what you expect to see in the output.
This particular MRU isn't something I've seen before, and it is interesting...I can clearly see the value of this data. If Patrick is willing to share some test data, I'd be more than happy to update the appropriate RegRipper plugin(s). As the author of RegRipper, I'm fully aware that I don't see everything that is possible to see in the Registry, and as such, I rely on the good will of the DFIR community when it comes to sharing data so that RegRipper plugins can be created or updated. For example, Eric Zimmerman recently shared some USRCLASS.DAT hive files with me so that I could update the RegRipper shellbags.pl plugin to be able to address shell items particular to Windows 8.1; I've updated some of the new folder shell items and I'm working on the MTP device shell items. I have also taken an opportunity to run the updated plugin against a USRCLASS.DAT hive from Windows 10 TP, but the content is limited. Therefore, so is the testing.
Also, if Patrick were willing to share what it is he doesn't like about the output of some of the available tools, I'd be happy to consider making changes to RegRipper output, as appropriate.
Speaking
I submitted two responses...titles and abstracts...to the HTCIA2015 conference "call for papers", and both were accepted. The conference is in Orlando, FL, at the beginning of September. Submitting for this conference was an interesting experience, as I started by asking what the attendees might be interested in hearing or seeing, and was told, in short, "yes!" My presentation titles are "Registry Analysis" and "Lateral Movement".
For the "Lateral Movement" presentation, I plan to discuss various methods of lateral movement within an infrastructure and what they "look like", with respect to the source and destination systems. I chose this topic as an example, and was told "yes!!" Also, I've been to conferences before where topics such as this are discussed, but there's been no real discussion or presentation of what the artifacts look like on systems.
I have something of an idea at this point regarding what I'm going to talk about during the "Registry Analysis" presentation, and I'm working on crystallizing it a bit. At this point, this is going to be an advanced presentation,
My question to you is, if you were to see a 1 hr presentation entitled, "Registry Analysis", what would you hope to get out of it? What would you look for to be discussed?
Kahu Security posted this recent blog article that was pretty interesting. I thought that the trick that was used was pretty interesting, and yes, "sneaky"...but part of me was wondering what this sort of thing would "look like" within a system image. What I mean is, if you're tasked with looking at an image of a system that may have been infected via this sort of trick, what would you look for?The first thing that jumps out at me is the warning displayed in Word, in the second figure in the post. Once the user clicks on the "Enable Content" button, a record is created within the user's MSOffice TrustRecords key. This information can be extract using the RegRipper trustrecords.pl plugin, or added to a timeline using the trustrecords_tln.pl plugin. These plugins were mentioned as part of the HowTo: Determine User Access to Files blog post from July, 2013.
Once the user clicks on the button and the macros are enabled, you'll see the other files described in the blog post created and launched within the file system. Because the command execution does not persist in memory once the process completes, this is an excellent argument for the use of tools such as Sysmon and Carbon Black.
If some of the files that are part of the infection process are deleted or time stomped, AND you can get to the system relatively quickly, a great resource for analysis is the USN change journal.
As far as recovering/extracting the actual macro itself, take a look at this blog post for some helpful hints and tools. Also, the folks at OpenDNS posted about Investigating a Malicious Attachment without Reversing.
Speaking of files being created on a system (see what I did there?), Mari has a new blog post up where she shares her experience using the USN change journal during analysis. As you can see in her excellent blog post, the USN change journal remains an excellent resource for obtaining extremely transitory information regarding system activity; while we don't know exactly which process is responsible for various files being created, we can see within a timeline when the various file system activities occurred, and this can not only provide additional context to a timeline, but it can also fill in some gaps in that timeline.
It's great that Mari is sharing her analysis experience with others, as it really helps those of us who may not have the same types of cases as she does, or those who may not approach (or "do") analysis in the same way. It's the sharing of those experiences, as well as asking questions, that builds a stronger community.
ADSs
I ran across Matt's recent blog post...what attracted my attention to it were the references ADSs and Powershell. ADSs are something I've been interested in for quite a long time, and I've included sections in my books that have discussed creating them, running code from within them, and what they "look like" to tools such as Carbon Black.
As to the post, there was an exchange on Twitter regarding the original content of the post, which centered around the use of the phrase "without touching disk"...Matt took the initiative to correct this, as you cannot create an ADS, and at the same time say that you aren't "touching disk". This is an interesting approach, and Matt's right...under most normal circumstances, at least the circumstances I encounter as an incident responder, something like this would go undetected by sysadmins. However, this is pretty trivial to address for an incident responder, using various artifacts, some that don't hang around as long (see this blog post), and others that persist for a while longer.
Registry Stuff
I recently ran across this post over on the System Forensics blog...unfortunately, as is the case with many blogs (it seems), comments are turned off, so I have to comment here...
Early on in the post, Patrick says:
Then I ran a few more well known tools and in one case didn’t see some of the entries at all, and in another case saw the entries, but no context was provided.
Interesting...which tools? Was anything done to contact the author(s)? Was any data shared so that the author(s) could make the appropriate updates?
At the end of the post, Patrick says:
If you’re simply relying on the output of a tool you’re possibly missing some good information.
He's absolutely right, which is why I strongly recommend that analysts get into the Registry when performing analysis, looking to see what's there. This is particularly true if there are any issues with tools that don't show you what you expect to see in the output.
This particular MRU isn't something I've seen before, and it is interesting...I can clearly see the value of this data. If Patrick is willing to share some test data, I'd be more than happy to update the appropriate RegRipper plugin(s). As the author of RegRipper, I'm fully aware that I don't see everything that is possible to see in the Registry, and as such, I rely on the good will of the DFIR community when it comes to sharing data so that RegRipper plugins can be created or updated. For example, Eric Zimmerman recently shared some USRCLASS.DAT hive files with me so that I could update the RegRipper shellbags.pl plugin to be able to address shell items particular to Windows 8.1; I've updated some of the new folder shell items and I'm working on the MTP device shell items. I have also taken an opportunity to run the updated plugin against a USRCLASS.DAT hive from Windows 10 TP, but the content is limited. Therefore, so is the testing.
Also, if Patrick were willing to share what it is he doesn't like about the output of some of the available tools, I'd be happy to consider making changes to RegRipper output, as appropriate.
Speaking
I submitted two responses...titles and abstracts...to the HTCIA2015 conference "call for papers", and both were accepted. The conference is in Orlando, FL, at the beginning of September. Submitting for this conference was an interesting experience, as I started by asking what the attendees might be interested in hearing or seeing, and was told, in short, "yes!" My presentation titles are "Registry Analysis" and "Lateral Movement".
For the "Lateral Movement" presentation, I plan to discuss various methods of lateral movement within an infrastructure and what they "look like", with respect to the source and destination systems. I chose this topic as an example, and was told "yes!!" Also, I've been to conferences before where topics such as this are discussed, but there's been no real discussion or presentation of what the artifacts look like on systems.
I have something of an idea at this point regarding what I'm going to talk about during the "Registry Analysis" presentation, and I'm working on crystallizing it a bit. At this point, this is going to be an advanced presentation,
My question to you is, if you were to see a 1 hr presentation entitled, "Registry Analysis", what would you hope to get out of it? What would you look for to be discussed?
Subscribe to:
Posts (Atom)