System security belongs to systems admins. The network to the network dudes. And the developers get to reign over the security of the apps they write. But where does something like the .NET framework fall? Sort of in between the cracks between system admins and developers. Developers don’t write it or manage the code, and systems admins most likely don’t know it very well either. (And I’m not even delving into consumer systems, just servers.)
Enter: .NET rootkits.
A .NET rootkit modifies the core framework DLLs from Microsoft (located in the GAC). A .NET rootkit may only be a symptom of a bigger problem: someone already owns your box hard enough to be able to replace framework files. But it might also be something that rogue developers can sneak into a production system. Even a sysadmin may taint something like an image base that other servers are built from.
It is probably a good idea to add some framework DLLs (or all of them) to any tripwire or digital integrity monitoring you have. If they change, an alert gets thrown. Caveat: I have not implemented such measures myself, so I don’t know if they change too often naturally. I assume they don’t.
Traffic egress should also be monitored. One purpose to rootkit an application is to siphon off its data. It can accumlate on the server (disk usage monitoring!), but ultimately it needs to get somewhere else to be useful to an attacker.
This doesn’t stop with .NET frameworks, but really any framework environment, such as Java.