Safer Windows Incident Response

Published: 2011-07-09. Last Updated: 2011-07-09 00:49:39 UTC
by Chris Mohan (Version: 1)
4 comment(s)

There's always a moment in any horror film where, inexplicably, one of the character, let's call him Chuck, wanders blindly into an obviously lethal encounter in a confined space. It's the "I'm just going down to the cellar to find out where everyone else has gone" moment that has most of us suddenly looking for a reason to run into another room to miss the grizzly outcome. Shortly after Chuck’s demise, one of the surviving cast clearly hears someone coming back up the cellar stairs and happily assumes it's just Chuck. Moments later they meet an equally horrifying end with some random household object.

Funny thing is a digital door to the cellar looms for an incident responder when investigating a report of a suspiciously acting system. Typically they're much better prepared and equipped than our fictional friend Chuck, but there is still a very real threat that crosses over from horror movies. What if the thing lurking on the system tries to stealing the digital identity of the brave incident responder? Suddenly we've got Good Ash and Bad Ash*, both with the same credentials access and privileges. The fight to contain an incident on just one system has now expanded to any system Ash's credentials has access to. This isn't a going to end well.

So how can we as incident responders on Windows systems protect ourselves against this?

Enter some fantastic research culminating in a presentation given at 2011 Digital Forensics and Incident Response Summit[1] by Mike Pilkington. Mike's talk, Protecting Privileged Domain Accounts during Live Response [2], covers the work he did to understand and protect the incident responder's domain credentials on remote Windows systems.

The presentation focuses on three areas where credentials are at risk from an attacker:

  • Password Hashes -Method for storing credentials on the local system
  • Access Tokens - Single sign-on functionality within Windows
  • Network Authentication -Protocols for authenticating to remote systems

This is worth printing out and spending some quality time going through. It discusses theses three areas of concern, takes you through the process so you can re-create each scenario and finally how to protect and detect against this type of attack.

After you've read it, take time to sit with your Windows Admins and explain to them the importance of protecting their credentials. This is well worth your time and energy educating any who has a privileged account. During an incident these folks need to be aware of the risk of remotely connecting to a possibly compromised system and how to do it safely. If you don't have a basic security training process for your system admin teams, this is a great starting point or ship 'em off and have some else educate them [3].

Once you’ve adopted Mike’s findings in to your incident response processes and into the Windows admins’ understanding, having your credentials used against be that one thing less to fear when facing that next digital cellar door. In the immortal words of Good Ash, to sum up, “Groovy.”

[1] http://www.sans.org/forensics-incident-response-summit-2011/agenda.php
[2] http://securityscaper.com/Protecting%20Privileged%20Domain%20Accounts%20during%20Live%20Response%20-%20June%202011.pdf
[3] http://www.sans.org/security-training/hacker-detection-systems-administrators-continuing-education-program-1312-mid

* Army of Darkness - so many lessons can be learnt, or one-liners stolen, for the IR world - Thank you Bruce Campbell!
 

Chris Mohan --- Internet Storm Center Handler on Duty

4 comment(s)

Comments

There is no way to "safely" remotely connect to a compromised PC. Any work being done on it while it is booted should be done while an airgap is in place.
I think the idea is that this is before a computer has been diagnosed as being compromised. Security responders frequently need to be able to gather info remotely, to identify computers that might be compromised. It's not feasible to assume all computers are compromised and air gap them all, so some middle ground has to be found, e.g. an acceptable level of risk management.
Rootkits (TDL4, etc) mean you cannot trust any answer you get from a client when diagnosing it, so it is pointless to ask. You need to use a combination of network data and logs exported from the host just before the compromise (with Snare or eventlog-to-syslog) so that you can make a proper diagnosis without using data the host has provided. Turning on process accounting and exporting logs in realtime is very effective in combination with IDS/web proxy data. In short, setting up comprehensive logging would be a better use of your time than working with admins regarding their credentials.
Great research Mike! - Thank you!

Diary Archives