Corporate Blogs
Two cool things about my day job is that I see cool things, and get to share some of what is seen through the SecureWorks corporate blog. Most of my day job can be described as DFIR and threat hunting, and all of the stuff that goes into doing those things. We see some pretty fascinating things and it's really awesome that we get to share them.
Some really good examples of stuff that our team has seen can be found here, thanks to Phil. Now and again, we see stuff and someone will write up a corporate blog post to share what we saw. For example, here's an instance where we saw an adversary create and attempt to access a new virtual machine. Fortunately, the new VM was created on a system that was itself a VM...so the new VM couldn't be launched.
In another example, we saw an adversary launch an encoded and compressed PowerShell script via a web shell, in order to collect SQL system identifiers and credentials. The adversary had limited privileges and access via the web shell (it wasn't running with System level privileges), but may have been able to use native tools to run commands at elevated privileges on the database servers.
Some other really good blog posts include (but are not limited to):
A Novel WMI Persistence Implementation
The Continuing Evolution of Samas Ransomware (I really like this one...)
Ransomware Deployed by Adversary with Established Foothold
Ransomware as a Distraction
VSCs
I watched Ryan Nolette's BSidesBoston2016 presentation recently, in part because the title and description caught my attention. However, at the end of the presentation, I was mystified by a couple of things, but some research and asking some questions cleared it up. Ryan's presentation was based on a ransomware sample that had been discussed on the Cb blog on 3 Aug 2015...so by the time the BSides presentation went on, the blog post was almost a year old.
During the presentation, Ryan talked about bad guys using vshadow.exe (I found binaries here) to create a persistent shadow copy, mounting that copy (via mklink.exe), copying malware to the mounted VSC and executing it, and then deleting all VSCs. Ryan said that after all of that, the malware was still running. However, the process discussed in the presentation wasn't quite right...if you want the real process, you need to look at this Cb blog post from 5 Aug 2015.
This is a pretty interesting technique, and given that it was discussed last year (it was likely utilized and observed prior to that) it makes me wonder if perhaps I've missed it in my own investigations...which then got me to thinking, how would I find this during a DFIR investigation? Ryan was pretty clear as to how he uses Cb to detect this sort of activity, but not all endpoint tools have the same capabilities as Cb. I'll have to look into some further testing to see about how to detect this sort of activity through analysis of an acquired image.
Sunday, August 28, 2016
Saturday, August 13, 2016
LANDesk in the Registry
LANDesk in the Registry
Some of my co-workers recently became aware of information maintained in the Windows Registry by the LANDesk softmon utility, which is pretty fascinating when you look at it. The previously-linked post states that, "LANDesk Softmon.exe monitors application execution..."...so not just installed applications, or just services, but application execution. The post goes on to state:
Unfortunately, if an application is no longer available the usage information still lives on in the registry.
This goes back to what I've said before about indicators on Windows systems, particularly within the Registry, persisting beyond the deletion or removal of the application, which is pretty awesome.
The softmon utility maintains some basic information about the executed apps within the Software hive, with subkeys named for the path to the app. The path to the keys in question is:
HKLM\SOFTWARE\[Wow6432Node]\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\
MonitorLog\<path to executed app>
Information maintained within the keys includes the following values:
This information isn't nearly as comprehensive as something like Sysmon, of course, but it's much better than nothing.
Sysforensics posted a LANDesk Registry Entry Parser script on GitHub, about 2 yrs ago. Don Weber wrote the original landesk.pl RegRipper plugin back in 2009, and I made some updates to it in 2013. There's also a landesk_tln.pl plugin that incorporates the data into a timeline.
Some of my co-workers recently became aware of information maintained in the Windows Registry by the LANDesk softmon utility, which is pretty fascinating when you look at it. The previously-linked post states that, "LANDesk Softmon.exe monitors application execution..."...so not just installed applications, or just services, but application execution. The post goes on to state:
Unfortunately, if an application is no longer available the usage information still lives on in the registry.
This goes back to what I've said before about indicators on Windows systems, particularly within the Registry, persisting beyond the deletion or removal of the application, which is pretty awesome.
The softmon utility maintains some basic information about the executed apps within the Software hive, with subkeys named for the path to the app. The path to the keys in question is:
HKLM\SOFTWARE\[Wow6432Node]\LANDesk\ManagementSuite\WinClient\SoftwareMonitoring\
MonitorLog\<path to executed app>
Information maintained within the keys includes the following values:
- Current User
- First Started
- Last Started
- Last Duration
- Total Duration
- Total Runs
This information isn't nearly as comprehensive as something like Sysmon, of course, but it's much better than nothing.
Sysforensics posted a LANDesk Registry Entry Parser script on GitHub, about 2 yrs ago. Don Weber wrote the original landesk.pl RegRipper plugin back in 2009, and I made some updates to it in 2013. There's also a landesk_tln.pl plugin that incorporates the data into a timeline.
Wednesday, August 10, 2016
Links
Data Exfil
A question that analysts get from time to time is "was any data exfiltrated from this system?" Sometimes, this can be easy to determine; for example, if the compromised system had a web server running (and was accessible from the Interwebs), you might find indications of GET requests for unusual files in the web server logs. You would usually expect to find something like this if the bad guy archived whatever they'd collected, moved the archive(s) into a web folder, and then issued a GET request to download the archive to their local system. In many cases, the bad guy has then deleted the archive. With no instrumentation on the system, the only place you will find any indication of this activity is in the web server logs.
However, for the most part, definitive determination of data exfiltration is almost impossible without the appropriate instrumentation; either having a packet sniffer on the wire at the time of the transfer, or appropriate endpoint agent monitoring process creation events (see the Endpoints section below) in order to catch/record command lines. In the case of endpoint monitoring, you'd likely see the use of an archiving tool, and little else until you moved to the web server logs (given the above example).
Another area to look is the Background Intelligent Transfer Service, or "BITS". SecureWorks has a very interesting blog post that illustrates one way that this native Windows service has been abused. I highly suggest that if you're doing any kind of DFIR or threat hunting work, you do a good, solid read of the SecureWorks blog post.
I am not aware of any publicly-available tools for parsing the BITS qmgr0.dat or qmgr1.dat files, but you can use 'strings' to locate information of interest, and then use a hex editor from that point in order to get more specific information about the type of transfer (upload, download) that may have taken place, and it's status. Also, be sure to keep an eye on those Windows Event Logs, as well.
Finding Bad
Jack Crook recently started a new blog, Finding Bad, covering DFIR and threat hunting topics. As
Jack's most recent post on hunting for lateral movement is a good start, but IMHO, the difference in artifacts on the source vs the destination system during lateral movement needs to be clearly delineated. Yeah, I know...it may be pedantic, but from my perspective, there is actually a pretty huge difference, and that difference needs to be understood, for no other reason that because the artifacts on each system are different.
Endpoints
Adam recently posted a spreadsheet of various endpoint solutions that are available...it's interesting to see the comparison. Having detailed knowledge of one of the listed solutions does a level set with respect to my expectations regarding the others.
MAC Addresses in the Registry
I recently received a question from a friend regarding MAC addresses being stored in the Registry. It turns out, there are places where the MAC address of a system is "stored" in the Registry, just not in the way you might think. For example, running the mountdev2.pl RegRipper plugin, we see (at the bottom of the output) something like this:
Unique MAC Addresses:
80:6E:6F:6E:69:63
I should also point out that the macaddr.pl plugin, which is about 8 yrs old at this point, also might provide some information.
Registry Findings - 2012
The MAC Daddy - circa 2007
EventMonkey
I ran across EventMonkey (wiki here) recently, which is a Python-based event processing utility. What does that mean? Well, from the wiki, that means "A multiprocessing utility that processes Windows event logs and stores into SQLite database with an option to send records to Elastic for indexing." Cool.
This definitely seems like an interesting tool for DFIR analysts. Something else that the tool reportedly does is process the JSON output from Willi's EVTXtract.
Presentations
As I've mentioned before, later this month I'll be presenting at ArchC0N, discussing some of the misconceptions of ransomware. I ran across an interesting blog post recently regarding, Fixing the Culture of Infosec Presentations. I can't say that I fully agree with the concept behind the post, nor with the contents of blog post. IMHO, the identified "culture" is from too narrow a sample of conferences...it's unclear as to which "infosec conferences" this discussion applies.
I will say this...I stopped attending some conferences a while back because of the nature of how they were populated with speakers. Big-named, headliner speakers were simply given a time slot, and in some cases, did not even prepare a talk. I remember one such speaker using their time slot to talk about wicca.
At one point in the blog post, the author refers to a particular presenter who simply reads an essay that they've written; the author goes on to say that they prefer that. What's the point? If you write an essay, and it's available online, why spend your time reading it to the audience, when the audience is (or should be) fully capable of reading it themselves?
There's another statement made in the blog post that I wanted to comment on...
We have a force field up that only allows like .1% of our community to get on the stage, and that’s hurting all of us. It’s hurting the people who are too afraid to present. It’s hurting the conference attendees. And it’s hurting the conferences themselves because they’re only seeing a fraction of the great content that’s out there.
I completely agree that we're missing a lot of great content, but I do not agree that "we have put up a force field"; or, perhaps the way to look at it is that the force field is self-inflicted. I have seen some really good presentations out there, and the one thing that they all have in common is that the speaker is comfortable with public speaking. I say "self-inflicted" because there are also a lot of people in this field who are not only afraid to create a presentation and speak, they're also afraid to ask questions, or offer their own opinion on a topic.
What I've tried to do when presenting is to interact with the audience, to solicit their input and engage them. After all, being the speaker doesn't mean that I know everything...I can't possibly know or have seen as much as all of us put together. Rather than assume the preconceptions of the audience, why not ask them? Admittedly, I will sometimes ask a question, and the only sound in the room is me breathing into the mic...but after a few minutes folks tend to start loosing up a bit, and in many cases, a pretty good interactive discussion ensues. In the end, we all walk away with something.
I also do not believe that "infosec presentations" need to be limited to the rather narrow spectrum described in the blog post. Attack, defend, or a tool for doing either one. There is so much more than that out there and available. How about something new that you've seen (okay, maybe that would part of "defend"), or a new way of looking at something you've seen? Want a good example? Take a look at Kevin Strickland's blog post on the Evolution of the Samas Ransomware. At the point where he wrote that blog post, SecureWorks (full disclosure, Kevin and I are both employed by SecureWorks) had seen several Samas ransomware cases; Kevin chose to look at what we'd all seen from a different perspective.
There are conferences that have already gone to taking at least some of the advice in the blog post. For example, the last time I attended a SANS360 presentation, there were 10 speakers, each with 6 minutes to present. Some timed their presentations down to the second, while others seemed to completely ignore the 6 minute limit on presentations. Even so, it was great to see a speaker literally remove all of the fluff and focus on one specific topic, and get that across.
A question that analysts get from time to time is "was any data exfiltrated from this system?" Sometimes, this can be easy to determine; for example, if the compromised system had a web server running (and was accessible from the Interwebs), you might find indications of GET requests for unusual files in the web server logs. You would usually expect to find something like this if the bad guy archived whatever they'd collected, moved the archive(s) into a web folder, and then issued a GET request to download the archive to their local system. In many cases, the bad guy has then deleted the archive. With no instrumentation on the system, the only place you will find any indication of this activity is in the web server logs.
However, for the most part, definitive determination of data exfiltration is almost impossible without the appropriate instrumentation; either having a packet sniffer on the wire at the time of the transfer, or appropriate endpoint agent monitoring process creation events (see the Endpoints section below) in order to catch/record command lines. In the case of endpoint monitoring, you'd likely see the use of an archiving tool, and little else until you moved to the web server logs (given the above example).
Another area to look is the Background Intelligent Transfer Service, or "BITS". SecureWorks has a very interesting blog post that illustrates one way that this native Windows service has been abused. I highly suggest that if you're doing any kind of DFIR or threat hunting work, you do a good, solid read of the SecureWorks blog post.
I am not aware of any publicly-available tools for parsing the BITS qmgr0.dat or qmgr1.dat files, but you can use 'strings' to locate information of interest, and then use a hex editor from that point in order to get more specific information about the type of transfer (upload, download) that may have taken place, and it's status. Also, be sure to keep an eye on those Windows Event Logs, as well.
Finding Bad
Jack Crook recently started a new blog, Finding Bad, covering DFIR and threat hunting topics. As
Jack's most recent post on hunting for lateral movement is a good start, but IMHO, the difference in artifacts on the source vs the destination system during lateral movement needs to be clearly delineated. Yeah, I know...it may be pedantic, but from my perspective, there is actually a pretty huge difference, and that difference needs to be understood, for no other reason that because the artifacts on each system are different.
Endpoints
Adam recently posted a spreadsheet of various endpoint solutions that are available...it's interesting to see the comparison. Having detailed knowledge of one of the listed solutions does a level set with respect to my expectations regarding the others.
MAC Addresses in the Registry
I recently received a question from a friend regarding MAC addresses being stored in the Registry. It turns out, there are places where the MAC address of a system is "stored" in the Registry, just not in the way you might think. For example, running the mountdev2.pl RegRipper plugin, we see (at the bottom of the output) something like this:
Unique MAC Addresses:
80:6E:6F:6E:69:63
I should also point out that the macaddr.pl plugin, which is about 8 yrs old at this point, also might provide some information.
Registry Findings - 2012
The MAC Daddy - circa 2007
EventMonkey
I ran across EventMonkey (wiki here) recently, which is a Python-based event processing utility. What does that mean? Well, from the wiki, that means "A multiprocessing utility that processes Windows event logs and stores into SQLite database with an option to send records to Elastic for indexing." Cool.
This definitely seems like an interesting tool for DFIR analysts. Something else that the tool reportedly does is process the JSON output from Willi's EVTXtract.
Presentations
As I've mentioned before, later this month I'll be presenting at ArchC0N, discussing some of the misconceptions of ransomware. I ran across an interesting blog post recently regarding, Fixing the Culture of Infosec Presentations. I can't say that I fully agree with the concept behind the post, nor with the contents of blog post. IMHO, the identified "culture" is from too narrow a sample of conferences...it's unclear as to which "infosec conferences" this discussion applies.
I will say this...I stopped attending some conferences a while back because of the nature of how they were populated with speakers. Big-named, headliner speakers were simply given a time slot, and in some cases, did not even prepare a talk. I remember one such speaker using their time slot to talk about wicca.
At one point in the blog post, the author refers to a particular presenter who simply reads an essay that they've written; the author goes on to say that they prefer that. What's the point? If you write an essay, and it's available online, why spend your time reading it to the audience, when the audience is (or should be) fully capable of reading it themselves?
There's another statement made in the blog post that I wanted to comment on...
We have a force field up that only allows like .1% of our community to get on the stage, and that’s hurting all of us. It’s hurting the people who are too afraid to present. It’s hurting the conference attendees. And it’s hurting the conferences themselves because they’re only seeing a fraction of the great content that’s out there.
I completely agree that we're missing a lot of great content, but I do not agree that "we have put up a force field"; or, perhaps the way to look at it is that the force field is self-inflicted. I have seen some really good presentations out there, and the one thing that they all have in common is that the speaker is comfortable with public speaking. I say "self-inflicted" because there are also a lot of people in this field who are not only afraid to create a presentation and speak, they're also afraid to ask questions, or offer their own opinion on a topic.
What I've tried to do when presenting is to interact with the audience, to solicit their input and engage them. After all, being the speaker doesn't mean that I know everything...I can't possibly know or have seen as much as all of us put together. Rather than assume the preconceptions of the audience, why not ask them? Admittedly, I will sometimes ask a question, and the only sound in the room is me breathing into the mic...but after a few minutes folks tend to start loosing up a bit, and in many cases, a pretty good interactive discussion ensues. In the end, we all walk away with something.
I also do not believe that "infosec presentations" need to be limited to the rather narrow spectrum described in the blog post. Attack, defend, or a tool for doing either one. There is so much more than that out there and available. How about something new that you've seen (okay, maybe that would part of "defend"), or a new way of looking at something you've seen? Want a good example? Take a look at Kevin Strickland's blog post on the Evolution of the Samas Ransomware. At the point where he wrote that blog post, SecureWorks (full disclosure, Kevin and I are both employed by SecureWorks) had seen several Samas ransomware cases; Kevin chose to look at what we'd all seen from a different perspective.
There are conferences that have already gone to taking at least some of the advice in the blog post. For example, the last time I attended a SANS360 presentation, there were 10 speakers, each with 6 minutes to present. Some timed their presentations down to the second, while others seemed to completely ignore the 6 minute limit on presentations. Even so, it was great to see a speaker literally remove all of the fluff and focus on one specific topic, and get that across.
Subscribe to:
Posts (Atom)