Intel, Tools, Etc.
Intel
One of the things I've been pushing for over the years is for IR teams to start (for those that haven't) developing intelligence from IR engagements, based on individual engagements, as well as correlating data across multiple engagements. If you're not looking for artifacts, findings and intelligence that you can bake back into your tools and processes, then you're leaving a great deal of value on the floor.
Over on Twitter, Chad Tilbury recently mentioned that "old techniques are still relevant today", and he's right. Where that catches us is when we don't make baking intelligence from engagements back into our processes and tools part of what we do. Conducting a DFIR engagement and moving on, without collecting and retaining corporate knowledge and intelligence from that engagement, means we're doing ourselves (and each other) a massive disservice.
Chad's tweet pointed to a TrustWave blog post that's just over four years old at this point, about webshell code being hidden in image files. I've seen this myself on engagements, and by sharing it with others on my team, we were able to upgrade our detection capabilities, and bake those findings right back into the tools that everyone used (and still use). Also, and it kind of goes without saying, sharing it in the public blog post informs others in the community, and provides a mechanism for them to upgrade their knowledge and detection capabilities, as well, without having to have experienced or seen the issue themselves.
Malware Research
I've always been really interested in write-ups of analysis of malware, in part, because I try to pull out the intel I can use. I don't have much use for listings of assembly language code...I'm not sure how that helps folks hunt for, find, respond to, nor understand the risk associated with the malware. Also, it doesn't really illustrate how the malware is actually used.
I recently ran across this write-up of PlugX, a backdoor that I'm somewhat familiar with. It's helpful, particularly the section on persistence. In this case, the backdoor takes advantage of the DLL search order hijacking vulnerability by dropping a legit signed executable (avp.exe) in the same folder as the malicious DLL. I've seen this sort of thing before...in other instances, a Symantec file was used.
Something I've wondered when folks have shared this finding is, what is the AV solution used at the client site? Was 'avp.exe' used because Kaspersky was the AV solution employed by the client/target? The same question applies regardless of which legitimate executable file was used
Tools
The folks over at Kaspersky Labs posted a tool for parsing Windows Event Log files on their GitHub repository. I downloaded the Windows x64 binary, and found that apparently, the tool has no available syntax information, as it takes only a file name as an argument. The output is sent to the console, as illustrated in the example below:
Record #244 2016.05.12-00:22:08 'Computer':'slimshady', 'Channel':'Application', 'EventSourceName':'Software Protection Platform Service', 'Guid':'{E23B33B0-C8C9-472C-A5F9-F2BDFEA0F156}', 'Name':'Microsoft-Windows-Security-SPP', 'xmlns':'http://schemas.microsoft.com/win/2004/08/events/event', 'Level':00, 'Opcode':00, 'Task':0000, 'EventID':1009, 'Qualifiers':16384, 'Keywords':0080000000000000, 'SystemTime':2016.05.12-00:22:08, 'ProcessID':00000000, 'ThreadID':00000000, 'EventRecordID':0000000000000244, 'Version':00, 'Data':'...//0081[004A]',
As you can see, this output is searchable, or 'grepable' as the *nixphiles like to say. It's a good tool for parsing individual *.evtx files, or you can include it in a batch file.
I ran across WHIDS (Windows host IDS) on Twitter the other day...seems like a great idea, allowing for rules/filters to be built on top of Sysmon, on workstations or event collectors.
On 10 Feb 2018, I found this pretty fascinating blog post regarding an MS tool named "vshadow". This is some great info about how the tool could be used. I blogged about this tool myself back in 2016, which as based in part on a Carbon Black blog post from the previous summer. If you're an analyst or threat hunter, or even a pen tester, you should most definitely take a look at all of this reading. The Cb blog in particular describes some pretty interesting uses of the tool that have been observed in the wild, and it's pretty crazy stuff.
On Writing Books
As the writing of my most recent book winds down and chapters (and the ancillary materials, front and back matter) are sent to the publisher for review, I feel less of the sense of urgency that I need to be working on the book, and my thoughts get freed up to think about things like...writing books.
With respect to the current book, there're always the thoughts, "...did I say enough..", and "...was that meaningful? Did it make sense? Will others understand it? Will something I said have an impact on how someone performs this work?" Even with the great work done and assistance provided by Mari, my tech editor, those questions persist.
The simple fact that I've had to make peace with is that no matter how much work I put into the book, it's never going to be "perfect"; it's not going to be everything to everyone. And that's cool. Really. I've seen over the years that no matter how much I talk about the books while writing them, at some point after the book is published, I'm going to get the inevitable, "...did you cover...", "...did you talk about...", and "...why didn't you say anything about..." questions. I get it. It's all good.
One of the things I've been pushing for over the years is for IR teams to start (for those that haven't) developing intelligence from IR engagements, based on individual engagements, as well as correlating data across multiple engagements. If you're not looking for artifacts, findings and intelligence that you can bake back into your tools and processes, then you're leaving a great deal of value on the floor.
Over on Twitter, Chad Tilbury recently mentioned that "old techniques are still relevant today", and he's right. Where that catches us is when we don't make baking intelligence from engagements back into our processes and tools part of what we do. Conducting a DFIR engagement and moving on, without collecting and retaining corporate knowledge and intelligence from that engagement, means we're doing ourselves (and each other) a massive disservice.
Chad's tweet pointed to a TrustWave blog post that's just over four years old at this point, about webshell code being hidden in image files. I've seen this myself on engagements, and by sharing it with others on my team, we were able to upgrade our detection capabilities, and bake those findings right back into the tools that everyone used (and still use). Also, and it kind of goes without saying, sharing it in the public blog post informs others in the community, and provides a mechanism for them to upgrade their knowledge and detection capabilities, as well, without having to have experienced or seen the issue themselves.
Malware Research
I've always been really interested in write-ups of analysis of malware, in part, because I try to pull out the intel I can use. I don't have much use for listings of assembly language code...I'm not sure how that helps folks hunt for, find, respond to, nor understand the risk associated with the malware. Also, it doesn't really illustrate how the malware is actually used.
I recently ran across this write-up of PlugX, a backdoor that I'm somewhat familiar with. It's helpful, particularly the section on persistence. In this case, the backdoor takes advantage of the DLL search order hijacking vulnerability by dropping a legit signed executable (avp.exe) in the same folder as the malicious DLL. I've seen this sort of thing before...in other instances, a Symantec file was used.
Something I've wondered when folks have shared this finding is, what is the AV solution used at the client site? Was 'avp.exe' used because Kaspersky was the AV solution employed by the client/target? The same question applies regardless of which legitimate executable file was used
Tools
The folks over at Kaspersky Labs posted a tool for parsing Windows Event Log files on their GitHub repository. I downloaded the Windows x64 binary, and found that apparently, the tool has no available syntax information, as it takes only a file name as an argument. The output is sent to the console, as illustrated in the example below:
Record #244 2016.05.12-00:22:08 'Computer':'slimshady', 'Channel':'Application', 'EventSourceName':'Software Protection Platform Service', 'Guid':'{E23B33B0-C8C9-472C-A5F9-F2BDFEA0F156}', 'Name':'Microsoft-Windows-Security-SPP', 'xmlns':'http://schemas.microsoft.com/win/2004/08/events/event', 'Level':00, 'Opcode':00, 'Task':0000, 'EventID':1009, 'Qualifiers':16384, 'Keywords':0080000000000000, 'SystemTime':2016.05.12-00:22:08, 'ProcessID':00000000, 'ThreadID':00000000, 'EventRecordID':0000000000000244, 'Version':00, 'Data':'...//0081[004A]',
As you can see, this output is searchable, or 'grepable' as the *nixphiles like to say. It's a good tool for parsing individual *.evtx files, or you can include it in a batch file.
I ran across WHIDS (Windows host IDS) on Twitter the other day...seems like a great idea, allowing for rules/filters to be built on top of Sysmon, on workstations or event collectors.
On 10 Feb 2018, I found this pretty fascinating blog post regarding an MS tool named "vshadow". This is some great info about how the tool could be used. I blogged about this tool myself back in 2016, which as based in part on a Carbon Black blog post from the previous summer. If you're an analyst or threat hunter, or even a pen tester, you should most definitely take a look at all of this reading. The Cb blog in particular describes some pretty interesting uses of the tool that have been observed in the wild, and it's pretty crazy stuff.
On Writing Books
As the writing of my most recent book winds down and chapters (and the ancillary materials, front and back matter) are sent to the publisher for review, I feel less of the sense of urgency that I need to be working on the book, and my thoughts get freed up to think about things like...writing books.
With respect to the current book, there're always the thoughts, "...did I say enough..", and "...was that meaningful? Did it make sense? Will others understand it? Will something I said have an impact on how someone performs this work?" Even with the great work done and assistance provided by Mari, my tech editor, those questions persist.
The simple fact that I've had to make peace with is that no matter how much work I put into the book, it's never going to be "perfect"; it's not going to be everything to everyone. And that's cool. Really. I've seen over the years that no matter how much I talk about the books while writing them, at some point after the book is published, I'm going to get the inevitable, "...did you cover...", "...did you talk about...", and "...why didn't you say anything about..." questions. I get it. It's all good.