How Well Do You Know
This work is licensed under a Creative Commons Attribution 3.0 License.
Don’t Be Stupid
The following presentation describes real
attacks on real systems. Please note that
most of the attacks described would be
considered ILLEGAL if attempted on
machines that you do not have explicit
permission to test and attack. I assume no
responsibility for any actions you perform
based on the content of this presentation
or subsequent conversations.
Please remember this basic guideline: With
knowledge comes responsibility.
The content of this presentation
represents my personal views and
thoughts at the present time. This
content is not endorsed by, or
representative in any way of my
employer nor is it intended to be a
view into my work or a reflection on
the type of work that I or my group
performs. It is simply a hobby and
personal interest and should be
considered as such.
Many ideas for this talk are derived from
“Managed Code Rootkits: Hooking Into
Runtime Environments”, Erez Metula,
Some ideas are from “Gray Hat Python”,
Justin Seitz, No Starch, 2009
Other Ideas are from colleagues far
Few ideas are my own
noun: rootkit; plural noun: rootkits
a set of software tools that enable an
unauthorized user to gain control of a
computer system without being detected.
A rootkit is a stealthy type of software,
typically malicious, designed to hide the
existence of certain processes or programs
from normal methods of detection and enable
continued privileged access to a computer.
The term rootkit is a concatenation of
"root" (the traditional name of the
privileged account on Unix operating
systems) and the word "kit" (which refers
to the software components that implement
the tool). The term "rootkit" has negative
connotations through its association with
• Runtime Environment/Application-Level
• Java JVM
• .NET Framework aka Common Language
• Android Dalvik
• Intermediate Language
• MS IL
• Managed Code
• C#, VB.NET, F#, etc.
// OK, let's be a little evil
IL_00XX: ldstr "C:UsersPublicmylog.txt"
IL_00XX: ldarg.0 // get the username
IL_00XX: ldstr ","
IL_00XX: ldarg.1 // get the password
IL_00XX: ldstr "rn"
// set the data (concatenate the pervious strings)
IL_00XX: call string System.String::Concat(string,string,string,string)
// write the data
IL_00XX: call void [mscorlib]System.IO.File::AppendAllText(string, string)
• Local Runtime?
• Signature Checking?
Starting with the .NET Framework 3.5 Service
Pack 1, strong-name signatures are not
validated when an assembly is loaded into a
full-trust application domain, such as the
default application domain for the MyComputer
zone. This is referred to as the strong-name
bypass feature. In a full-trust environment,
demands for StrongNameIdentityPermission
always succeed for signed, full-trust
assemblies, regardless of their signature.
The strong-name bypass feature avoids the
unnecessary overhead of strong-name signature
verification of full-trust assemblies in this
situation, allowing the assemblies to load