When it comes to performing the technical aspects of incident response and forensics on Windows systems (ie, data collection and analysis), what keeps you up at night? What are your concerns?
I'm sure everyone has a different perspective on this. A LE-based forensic analyst may have one set of concerns that may or may not overlap with those of an admin, or first responder. Does someone in a corporate environment have different concerns from those of someone managing a web hosting environment?
Are you concerned about finding out what happened, what the root cause was? Are you concerned with "bringing the perpetrator to justice?" Are you of the opinion that there are simply too many dark, dusty corners to look in, so better to just re-install the operating system from clean media and move on?
I think your thoughts and opinions would go a long way toward addressing issues such as reference materials, postings, training opportunities, etc. Please free to comment here, or email me. I'd like to provide a summary of the responses I receive (anonymized and sanitized, of course). I'd also like to ask that if you do respond, please indicate your role in some way. Thanks.
A couple of things that keep me awake are large storage devices, (SANS), and making sure I know the vector the bad guy used to comp the box. So far I have been lucky and not been taken to task by either scenario but the time will come when my luck runs out.
ReplyDeleteWith large storage, the only thing I have really been able to come up with are getting what you think might be relevant and hope you got it all, use provided backups software but where do you get the space to backup a SAN and who is to say the backup software wasn't also comp'd? And then I guess for RAID's you could hot swap if possible but there again is the HW issue.
Being able to find out how a bad guy got in and did his duty has always been in the back of my head. Making sure that when I put the box back into production, the same vulns don't exist or I have been able to take proper corrective actions keeps me up.
Oh, my role is part of the corporate CIRT team.
ReplyDeleteBrandon,
ReplyDeleteHow do you go about your root cause analysis? What tools/methodologies do you use in order to determine the infection or attack vector?
On windows boxes it is the first thing that I will start is gathering volatile information before unplugging the box. Those tools include openports, pmdump, the pstools suite, cmdline, uptime, and when I am doing my own work I use the FSP. I am still in the process of getting it use approved through my organization.
ReplyDeleteDepending on the results gathered from these tools I make an assumption based on previous experience or some of the clues from those tools and will then begin looking at the non-volatile data a once the box has been unplugged.
We/I haven't had one hit (that I am aware of), once it has been placed back online. One thing that I am sure everyone does is monitor the heck out of that box once it goes live again. IDS, system logs, FW logs, etc. The attacker will try getting back in using their normal vector and if that doesn't work, they may try how they initialy infected the box.