Memory Forensics During Incident Response. Jack Crook. Incident Handler. Works for GE. Founded RaDFIRe. Handlerdiaries.com. IR in a nutshell. Consider the following scenario.
Works for GE
It’s been a long night and you finally get to bed only to be woken up 30 minutes later to the sound of your phone alerting you that there’s an alert that fired and needs to be triaged immediately. Crawling out of bed you’re thinking this has to be a false positive because you’ve gone through this same routine each of the past 5 nights you were on call. Not bothering to turn the lights on for something that’s sure to be random noise, you peer into the ids console and see an alert that you have never seen before. You automatically think to yourself, being the tired analyst that you are, “who was the a$$hole that added this new rule”, and you’re sure it was added intentionally just to keep you awake, but you know you can’t get back to bed until the alert is validated. So you begin sifting through the data and it quickly becomes apparent that this isn’t a false positive, but rather it’s the real deal and alerted to the fact that there’s an intruder in your network attempting to move laterally. You double check your initial analysis and you come to the realization that you’re not going to feel the comfort of your bed for a long long time to come. As the adrenaline begins to rush, your mind starts racing, thinking about everything that needs to happen and you know you need to act immediately.
Memory is one if the richest pieces of data to collect when analyzing host data
Complete system state
Recover artifacts of compromise
Identify command execution
How was the host compromised?
Is the host compromised?
Were malicious files dropped?
Who talked to the host?
Who did the host talk to?
Were any user accts compromised?
Was any lateral movement identified?
How was lateral movement performed?
Was any data taken from the host?
Do additional hosts need investigation?