Thoughts on using a "trusted shell"

Recently I've seen the topic of using a "trusted shell", especially when performing live response on Windows systems, brought up in a couple of forums.

The idea of a "trusted shell" comes from the use of statically-compiled binaries on *nix systems, where the actual executable file carries with it it's own libraries and does not rely on libraries on the "victim" system. The idea is that if the actual shell binary or any of the dependent libraries have been compromised, the responder can still get accurate information due to the fact that she's using a "trusted shell". And, of course, there's always the concern about "rootkits", but whenever I see a post or email that includes a reference to rootkits, my FUD radar goes off; in most cases, I don't think that folks understand rootkits, per se. For example, why say that you're only going to use a "trusted" cmd.exe because the cmd.exe on the system may have been subverted by a rootkit, when your "trusted" cmd.exe is going to use the same DLLs as the native one? I mean, most rootkits hook or subvert API functions, not executables.

Mapping this to the world of Windows incident response, one has to ask, how do you statically compile an executable for Windows? Can you even do this? At some point, you're going to have to rely on an MS-provided DLL, and its all a matter of how deeply the system has been compromised. After all, if the intruder is able to compromise extremely low-level APIs to the point of tricking the kernel, it's game over!

Even using SxS manifests will very likely present their own unique set of problems, particularly since most currently available tools and applications don't use manifests and would need to be rewritten.

Finally when running cmd.exe, there are a number of ways to subvert the use of just that executable without ever touching or modifying the EXE or any of its dependent DLLs. One is through the use of the Command Processor\AutoRun Registry entry (HKLM or HKCU), one is through the exefile Registry entries, and another is through the Image File Execution Options Registry key.

So that leaves me with the question of, why are folks stressing so much about "trusted" shells, when we can't even figure out what that is?

Another way to look at this is that if we've done our IR planning, maybe we want the operating system to lie to us. Think about it...if we're using some form of differential analysis, wouldn't we want to run "netstat -ano" on a system, and then compare that output to a packet capture, firewall logs, or even an nmap scan? Or how about using tools that use disparate API calls, such as perhaps pslist.exe and handle.exe, to get similar information (ie, process listing)? Wouldn't we get some benefit from quick, automatic parsing of the data that would highlight disparities in the output? Let's say you're seeing a steady stream of data flowing from a system, and you have firewall and IDS logs, as well as a packet capture, and the output of netstat shows in indication of the use of the port? Wouldn't this sort of analysis provide us with something useful, and obviate the need for speculation and assumption?

What are your thoughts?