Ah, that's the key, though, isn't it.sharing the information and intelligence. So, we can learn from our own cases, but we can also learn from what others have learned and shared. What better way to go from GB or TB of raw data to a few KB of actual information, with the context to turn that information into intelligence, than to do so working actual DFIR cases? Ultimately, that's where it all starts, right? However, I found (and still find) a great deal of value in having a documented process or workflow, and I continue to use and develop my own.Īll this talk of processes and workflows logically leads to questions of, where do I get the data and information that I turn into intelligence and incorporate into my workflows? Well, for the most part, I tend to get the most intel from cases I work.
Further, after I drafted the workflows, they were neither reviewed, nor actually used. Interestingly enough, some of those who said this are now active bloggers. Not long ago, with a previous employer, I was asked to draft analysis processes and workflows, because other analysts said that they didn't "have the credibility". Even if I never see the event again in the next 999 cases I work, that 1000th case where I do see it will make it worth the effort to document it.ĭocumenting processes and procedures for many is a funny thing. However, based on what it means, and the context surrounding the event being recorded, it was most definitely something I wanted to incorporate into my analysis process. Having the process automated means that I spend less time doing those things that can be automated, and more time actually investigating those things that I need to be.well.investigating.Īn example of this is eventmap.txt I did not actually work the engagement where the event source/ID pair for "Microsoft-Windows-TaskScheduler/709" event record was observed. As such, as I learn something new, I add it to the process, so that I don't forget something.God knows that most days, I can't remember what I had for breakfast, so how am I going to remember something that I read (didn't find or do as part of my own analysis) six months ago? The simple fact is that I don't know everything, and I haven't seen everything, but I can take those things I have seen, as well as what others have seen (culled together from blog posts, etc.) and incorporate them into my process. Also, the documented process serves as a means for automation. Why is that? Well, for me, a documented process is a living document, one that is continually used and updated as necessary. My experience has been the documenting my analysis process for activities such as malware detection within an acquired image, I'm able to ultimately spend more time on the fun and interesting aspects of analysis. Perhaps the argument I've heard against documented processes over the years is that having them "stifles creativity". I mention these two specifically because from my perspective, they seem to be diametrically opposed after all, what is a volatile data collection script but a documented process?
This is pretty cool stuff, and I can see it being included in volatile data collection processes going forward.Ī couple of things I've seen during my time as an incident responder is (a) a desire within the community for the "latest and greatest" volatile data collection script/methodology, and (b) a marked reticence to document processes and procedures. Either way, this would be a great addition to any volatile data collection script.
The output is in a table format, but for anyone familiar with Powershell, I'm sure that it wouldn't be hard to modify the output to CSV, or some other format. I downloaded and ran the Powershell script from a command prompt (not "Run as administrator") using the following command line:
Precious disk image passwords ftk lord of the rings windows#
However, Hadar demonstrates that there is a way to get time stamps for network connections on Windows systems, and wrote a Powershell script to do exactly that. We simply don't remember that MS did not create an operating system with DFIR in mind. Specifically, Hadar Yudovich recently authored an article on the Illusive Networks blog about finding time stamps associated with network connections. His blog post is pretty fascinating, as he says some things that are probably true for all of us in particular, we'll see a native tool (such as netstat.exe), and assume that the data that the tool presents is all that there is. It's been a while since I posted anything on the topic of live response, but I recently ran across something that really needed to be shared as widely as possible.
0 kommentar(er)
