Good morning.  So everybody that's like from
the middle half of the room, if you all want to come up
a little bit, there is going to be some slides here
that have some code on it.  The code has really tiny
text.  My eyesight isn't that good that far back.
Trying to do a favor to y'all to come forward so you
can see what is going on.
     With that here is Topher.
     >> Awesome.  Thanks for having me.  This is my
first time speaking at DEFCON and my first time
attending and I'm blown away at the caliber of this
community.  Thank you for coming to the talk.  This is
hijacking arbitrary .NET application control flow and
I'm going to screw up sot .NET applications.
     Who am I?  I'm a security researcher at Intel.
Previously doing research in Ashland, Oregon in
Southern Oregon University.  I've done a little bit of
security training.  I did a talk on .NET hacking in
Oslo, Norway and occasionally blog and tweet.
     .NET, why the hell do any of us care?  Like I
said, I was at the new developers conference in Oslo
and 80 percent of the attendees there were .NET
developers.  There is constant jobs up online for this.
SQL databases, fingerprint readers, et cetera.  There
is a big market for .NET but there aren't really people
attacking .NET.
     I'm going to go through run time attacks in the
.NET.  Manipulating the just in time compilation
process, manipulating things at the machine code level.
Modify control flow in .NET applications, taking
branches and changing them arbitrarily to things that
you control to do something different in the
application that is evil.
     And then I'm going to show you machine code
editing in .NET.  This is not a common practice now.  A
lot of people are doing ILD compilation and changing
bytes at the ILD level and these are on disk attacks so
I'm going to go down to machine code.  And manipulate
the [indiscernible] which is the mechanism that .NET
uses to store all objects.  It's unprotected.  We can
go through and rip off objects that are instantiated
and and use them ourselves.
     I'm releasing tools for this demo.  And then we're
using .NET to attack.  Not many people are operating in
the space which I think it's cool.  And then of course
we're using objects on the manage -- which isn't
something that's been done too much before and I think
you're going to enjoy it.
     When I talk about CLR attacks or the common
language run time, I'm talking actual run time.  You
have a process running on a machine, a C application,
that's the process.  In .NET there is a level
underneath that called the CLR and it's a container for
the .NET instance.  A process inside a process.
     Two versions of the CLR, version 2 and 4.  And
when you're building attack pay lows for C sharp you
have to worry about the target application but we don't
have to worry about that anymore because I took care of
the work and now we can use any payload and not care
the version.
     With a CLR that is where the sheep is living.
It's a run time concept where objects are being stored.
That's essentially a part of attacking the CLR.
     If we dive down into a .NET process, we have at
domains, giant containers for running code and they
contain the actual executable that we're running and
all of the DLLs that we're running.  Those are called
assembles.  Within an app domain, there can be more
than one but it's no common.  And utilizing that
commonality, because of this we can control all loaded
code.  If we have access to the CLR itself we can just
in time the compilation process.
     Assembly or ASM, assembly is a module like a DLL
or executable, we can manipulate the resources of it.
Go through and edit the method tables.  Call in machine
code at .NET to go through structures and enumerators.
And then of course attacking methods purely at the
machine code level.
     So here is a kind of layout of the run time.  You
have the processor, the CLR and app domains and
assemblies and like any other language.  Objects with
properties, fields and instance methods and classes
that contain static methods and the core logic of the
application.
     Now that we have an idea of what a .NET process
looks like and what these tools are going to be doing,
I'm going to jump into them instead of boring you with
the details of .NET.
     Gray frost and gray storm are two tools but acting
in tandem for this.  Gray frost is a DLL that you
inject and it's a boot strapping process to bind the
payload into the .NETCLR.  And gray storm is the
payload that I'm delivering are gray frost.  Gray storm
is written in C sharp that attacks .NET.  Gray frost in
detail.
     Gray frost is the payload delivery system.  A C++
DLL that acts as a DLR boot strapper.  It's going
through and figuring out what methods to call within MS
query which is the main CLR, DLL.  It calls a bunch of
methods that create or inject into the CLR run time.  I
mentioned there were two versions of the CLR, version 2
and version 4, this payload delivery system has the
capability to pivot into the 2.0 run time if needed.
This gives us the mechanism to not care about the
target application running is, and insert an arbitrary
payload like gray storm.
     Gray frost contains the ray payload
[indiscernible] once through the boot strapping process
and it's in the proper version of CLR it fires the
payloads void main.  It does this in two rounds.  The
first round is gray frost CPP.  This is the DLL bots
process.  And after that process finishes it's going to
fire the C sharp payload.
     So graphically this is going to look like this for
round one which is gray frost CPP.  The .NET process is
running.  This can be on a box that we have physical
access to, remote, it doesn't matter.  All we need to
do is do DLL injection.  You can utilize a tool called
gray dragon.  Doesn't matter.  Inject the DLL however
you want.
     Once it's spinning it pivots and calls the needed
methods and instantiates the CLR.  And C sharp, at this
point we're in the proper version of CLR, 4.0.  So we
have our .NET process with gray frost C sharp running,
the right version of the CLR and now the payload is
running in tandem.
     If we have to pivot with the run times -- you
might think it's not common because 4.0 is the newest
and greatest but developers are lazy so a lot of things
are 2.0 unfortunately.  It's not more of a step.  I did
the work for you.  After injection and after it
..(audio blipped).. gray frost C sharp.  Gray frost C
sharp realizes that the app domain name is default.
     If it's labeled as default that means the target
application isn't running an app domain because
..(audio blipped).. name associated with it and I'm
making default when I inject.  Gray frost C sharp comes
into C++ we pivot to MS query and do clean up and fire
in the proper version of the CLR.
     So that's gray frost in a nutshell.  It's being
open-sourced so you can read the code of how all that
is made possible.  Let's get into gray storm.
     Gray storm our reconnaissance and in-memory attack
payload.  Several features that attack .NET at the
assembly level and run time level.  We're going to be
able to do things like attack the .NET just in time
compiler.  If you're not familiar with that, when you
hit compile button, you're not generating run able
machine code.  You're doing an intermediate level
language and at run time the IL code is just in time
compiled down into the actual machine code that is ran
by the CP for that particular method.
     We're going to be able to with gray storm attack
.NET at the ASM level.  Rip pointers off of messages
..(audio blipped)..
     In demonstrate -- own assembly payloads and
utilize -- payloads.  There are subtle differences
between the two.  Then utilize objects on the managed
heap.  Usage of gray storm.  Controlling the just in
time compiler.  When you have just in time compilation
of the debt net framework when method A is calling to
method B, method B contains a table that I'm calling
the just in time compilation stub.  That contains an
address to where the IL code and machine code is going
to be generated.
     Because we know this, and because Microsoft chose
to leave in the framework all this stuff unprotected,
we can go through and grab the tables, overwrite with
anything we want and control the just in time compiler.
..(audio blipped).. this is not possible and you're
going to need to do something at the machine code level
or wait for something to get garbage collected.  At
that point something is going to be just in time
compiled again because the .NET framework made room for
something else.
     Graphically this look likes this in the demo.
Method A calls method B.  What we can do is take a
hacker method with a git stub.  Redirect method B and
now method A is going to call hacker method instead.
     I'm going to open up a target application now.
This is a pretty cool mark down editor for Windows.
I'm not running Linux right now.  Here is gray dragon,
a remote DLL injector.  It has cute cross hairs to drag
to the target application.
     I've done some editing where it ..(audio
blipped).. version of gray frost I need to inject.
Because this payload delivery system is going to
account for the differences in 32 and 64 bit targets.
Once I inject it's going to inject gray frost, and it's
going to go through the entire boot strapping process
and spin up gray storm.
     I injected it.  It did the boot strapping process
and it's running in the 4.40 version of the CLR.  I'm
going to do a quick run through of this application.
     You can see on the left side, this is inside of
the main app domain and you're seeing the assemblies
within the domain, the main executable mark down and
the DLLs it needs:  You can keep going down further and
further into each of these.  Go until something like
[indiscernible] look at the methods it contains.  Dump
the assembly so I can see the raw machine code for the
method after it's compiled.  Look at the IL code for
the thing.
     Shows where the address of the machine code is.
Attach this application in windows D bag.  I breakpoint
on methods which is a little easier than having to
track them down.
     Let's go through and attack this just in time
compilation process.  There's a licensed feature in
mark down pad two that allows you to export to a PDF
and currently I have a license for it.  I'm able to do
this easily.
     I want to change that feature and I want to insert
my own method there.  I don't want to wait for the just
in time compiler, I'm going to close out of that.
Reopen the target application.  I'm going to drag the
cross hairs back over it, inject back in and then I'm
going to come here to the dynamic C sharp Window.  This
is going to allows us to compile new codon the fly
which I prepared.
     I'm going to pop up a message box that said owned
and returned false because I don't want a license for
this application anymore.  I'm going to paste that here
and ..(audio blipped).. now it's over here in the
methods list and I can fire it to make sure it works.
It says owned.  Awesome.
     If I come back over here and trace down
[indiscernible] here called licensing helper.  And then
a Boolean value late license.  I'm going to say replace
method with custom C sharp and it says [indiscernible].
Come here to file export, export PDF and now I'm owned
and I don't have a license anymore.
     So that's attacking something before it's been
just in time compiled.  If you want to attack something
and don't want to restart the application or wait, you
can do things at the machine cold level.  In .NET there
is far and relative calls.  You can take because I
showed you how easy it is to dump the may sheen code or
overwrite it.  Figure out what call instructions is
going to the method it's calling and replace them and
change them.
     This is a way to attack something when you don't
want to wait because you're lazy or want to do it now.
If we read the Intel manual that calculating a relative
call address at run time is little bit difficult.  But
there is source code where you can read this and how I
made it easy with a simple method call.
     Now we get into actual machine code payload.
Utilizing reflection which name space [indiscernible]
allows you to see things like the assemblies, the app
domains and meta data about specific methods.  One of
the things this lets us see is where the machine code
is ..(audio blipped).. and unprotected in memory.  We
can take it and change it.
     So we can create payloads to do things like steal
stack programmers.  A method of interest that is taking
in a password.  Steal the password and send it to email
server and return the password back to the application
and you stole stuff.  A mouse click isn't a mouse
click, it does other things behind the Seans and then a
mouse click.  It's up to your imagination.
     The most quick approaches is changing ..(audio
blipped).. and false to trues.  Because developers are
awesome in they modulate code really, really well.  So
there is always this low hanging branch of a return
tree with a password or license check.  Password
validation can be bypassed easily.  So can key and
licensing validation.  SQL sanitization can be bypassed
if it's returning down.  Has this been sanitized yet,
yes or no.  It has been, I'll pass it along to the
server.
     There can .NET security mechanisms that I won't
name.  But you can rip them apart and destroy them and
grab things off the happy like agent, objects,
et cetera, steal stack parameters, do whatever and rip
apart security at the assembly level.
     And really we're overwriting logic and we're
hackers to update mechanisms are always juicy.
     Graphically this looks like this.  Assume you have
this Boolean verified license that takes parameters and
checks for a valid license.  After produces assembly
code that you don't want to disassemble, return one and
now the developer wrote return true.
     Let's demo.  I'm going to open gray dragon and
Windows PowerShell ISC.  It's a scripting environment.
You can ping level three which is not going to work
because I'm not connected to the DEFCON wireless,
because screw that.
     So I'll drag my cross hairs back into that.  It's
a 32 bit application so I'll injects.  Here is gray
storm, it's in the version 2.0 of the CLR.  This is
running an older .NET version.  Gray frost accounted
for that.
     Within this application there is a run script
button.  So I'm going to find it.  So I know that it's
in this Microsoft PowerShell GP PowerShell assembly.
If I pivot down there is this thing in PowerShell tab
and it's void execute script.
     So this method right here, if I dump the assembly
is doing all that manipulation to run whatever is in
that text box, I can look at the IL code, I can
disassemble it if I want to.  I would have to inject B
engine DLL which is an open-source disassembly.  I'm
not going to go through this.  You can do that.
     I'm going to come here to show you how easy it is
to roll a meta exploit payload.  I'm going to show you
an alias called DEFCON.  It pops a calculator.  I will
run that and this takes time because I'm encoding it
and whatnot.  Once it finishes I have a payload that
pops a calculator.
     I'll come over here and drag over and copy it.  I
will come back over here to gray storm.  Go to the
shell code tab which has a couple of payloads that I'm
including ..(audio blipped).. return false and Miranda
warnings SS calculator payload.  I'm not going to use
that one.  I come to the editor and paste the payload.
I'm going to name it DEFCON.  And I create the shell
code.
     DEFCON meta exploit payload.  I can say fire it.
If I come here and I have this execute script method
selected and I say dump assembly.  That changed to the
meta exploit payload.  If I come to Windows PowerShell
and run script, I popped a calculator.
     So that's utilizing machine code payloads.  You
can rule your own.  The most important thing to know if
you want to use a meta exploit payload or run your own
there is a change that causes headache.  In the
portable environment block.  You need to find out the
base address of kernel 32 to get address and load
library.  That is commonly the third entry in the
memory order module listing.
     However in .NET applications it's the fourth.  So
you have to change your one line of code in the payload
to account for that dins.  If you're using a meta
exploit payload make sure they're doing this otherwise
you're going to crash the target application and if
you're doing this on an enterprise level thing, you're
going to have a bad time and somebody is going to catch
you.
     Object hunting and memory.  Now we attacked the
just in time compiler.  What about at run time.  What
about getting things off the managed heap.  It's the
storage point for all .NET run time objects such as
things that are instantiated by the application
application and the things that the user is doing.  And
occasionally remove dead objects and make room.
     We don't care how it works, we're going to
manipulate the crap out of it.  When we do object
hunting in memory, what we need to realize is that
there's a lot of pointers in .NET.  And objects are
actually pointers, an instance of the object on the
managed heap.  This object instance contains meta data
about the object.  What fields and properties are
currently set on it.  A method table.  This method
table tells the object instance what method
instantiated this thing and all objects of the same
type share the same method table.  We'll utilize that
in a signature.
     We're going to utilize an object hunting signature
that I created and then we're going to win.  In order
to do this there is a 6-step methodology that you need
to take as an attacker trying to rip objects off the
managed heap.  It's inspired by the way the volatility
guys do pool scanning.  Essentially ..(audio blipped)..
construct an object and find the location of the
managed heap.  Reflection gives us the ability to look
at what address is machine code running at for a
particular method.
     This isn't the case with the managed heap and we
need to do trickery so tell us where it is at run time
and construct a reference object to figure out what the
method table is for all of these objects.
     Step two is we're going to signature that
instantiated type.  Use a little bit of machine code to
pars that structure that the object instance is and rip
off some particular things that we ..(audio blipped)..
and step 3 is do a brute force approach to scan the
managed heap for other object pointers that are the
same as this object we're interested in.
     Step four is convert those objects into raw
objects.  When you do this something cool happens.  And
profit.
     So step one, construct an object.  Essentially
utilizing reflection we're able to go through and pars
through all of the app domains and all of the
constructors for a particular class.  We can ..(audio
blipped).. out knowing anything about it and
instantiate anything.  There is some objects that
will -- complex object types as arguments but we don't
really need to scare about that, we don't want to
utilize this object.  ..(audio blipped).. have one to
reference.  So we can just nullify all arguments in a
constructor and we'll will able to use it how we need
to.
     So then what we're going do is once we have an
instantiated object we're going to build a stack frame.
You can see at the top of the diagram here that I have
the raw object that I just instantiated and it has a
pointer associated with it.  This pointer is hidden
behind the Seans in the object type.  So with a little
bit of stack manipulation.  You can read the gist for
this.  We know that this object points to the location
of the managed heap which could be anywhere.  At the
top, the bottom, in the middle which is why we need to
do a brute forcing approach in memory.  We're going to
move that object down into the in pointer location and
we have the pointer to that object and the pointer of
the managed heap.
     Have an actual object created with an address of
the managed heap, we signature that instantiated type.
So object instances like I said contain a method table
pointer back to the type that instantiated them.  In 32
bit this is byte 033.  So we grab that and also the
instant size of this objected.  This allows us when
going down the managed heap, we don't need to do brute
force by jumping 4 or 8 bits, we can jump the size of
each object to get to the bottom to save time.  A
subtle different in 64 bit.  Primarily just the size of
the pointer.  That is all taken care of as well.
     Now that we have an object and signature it, we
scan the managed heap.  This is somewhat of an approach
to how the volatility guys do pull tech scanning.  They
brute force through memory with a specific structure
and innumerate on the structure to make sure what
they're looking for matches the memory they found.  I
do this by -- down the managed heap by the size of the
object that I rip off of each object's method table.
Grab the instance size off all of them and skin down.
When I find one that matches, I grab that pointer.  I
have a listing of all pointers of objects that I care
about.
     If I want to go up the managed heap, I have to
scan up it by 4 or 8 increments and a little bit of
access violation errors.  It's a decent signature now.
If somebody has a better approach, submit me a request
and let's make it better.
     Now other object pointers.  Convert the object
pointers back to objects.  Here is code to show this.
There is unsafe code that allows you to do pointer
manipulation in .NET.  What a lot of people say is this
is a compile check.  If you're compiling .NET and
trying to do safe code, it's like that's not cool.  Are
you sure.  You have to allow it.
     In memory where this didn't allow the compile
time, it doesn't matter because it's not a run time
check so who cares.  We're building a stack again, the
reference object that we're putting pointers back to.
And then we have an address that we grabbed off of the
managed heap to another object.  All we're going to do
is move the pointer lower on the stack and put it over
that reference.  And then what's magic about .NET is
when you give an object, a pointer to another object,
it will reference the instantiated object for you and
now you have a new reference to something that was on
the managed heap.  This is how we can go through and
instantiate an object and scan for all other objects of
that type and utilize them.
     Now we will learn all the things about the
application.  So what I'm going to do is open up a
fingerprint reader software that is sent on all laptops
of a specific manufacturer that won't be named.  Inject
gray frost.  And open up gray storm.  So now what I'm
doing is I'm going to open up the GUI more.  I'm not a
GUI developer.  I'm a hacker.  The GUI is not too
great.
     But essentially this method editor functionality,
it shows all objects and instance methods and fields
and properties and on the left the QLCLR user class and
constructor.  The constructor is taking two complex
object types, a passport and -- object.  Like I said
you can nullify those.  I added two nulls and called
that constructor.  And you can see this thing has a lot
of instance methods.
     One of the instance methods is get the Window's
password in plain text text.  I hit get all objects.  I
didn't get an object.  That's because I haven't
validated that I am who I say I am.  I swiped my finger
and logged in.  I'm calling that constructor.  I get
all objects off the managed heap.  I'll open QLCLR user
and go to the properties field and you can see that I
have a plain text system plain text passwords and
Hunger Games rocks.
     Now we have all of the superpowers and things.
Never before have we been able to go through the
managed heap and grab objects that we're interested in.
We can go through and essentially construct any object
we want and grab any object we want of that type.  It's
common that crypto objects have in a field or a
property, the key that is being used.  The salt that's
being used.  Go through and find those things and then
change them to keys that you have so everything in the
database is encrypted and they can never access
..(audio blipped)..
     And of course those instance ..(audio blipped)..
you can go through and call them.  You can call them
with arguments if you want to.  Say in the instance of
that constructor it took two object types, you can
build a chain and build an object type and build an
argument path.  The possibilities are endless and up to
you.
     This is a GUI.  We're hackers, GUIs suck.  All of
these payloads can be automated.  So gray frost is just
the injector platform, a DLL.  It doesn't map the
payload.  You can use a python script like autofrost.
Give it a C sharp payload with automation of something
behind the scans, and inject into a target application
and have it run.  So automations is loved so I'm going
to attack that fingerprint reader and show you that I'm
not crapping you and you can automate stuff.
     I'm going to swipe my finger and authenticate with
this application.  Grab gray dragon, inject gray frost
which is an automated version of the payload and Hunger
Games still rocks.
     When it comes down to constructing attack chains,
it's relatively easy to attack .NET applications due to
the nature of this just in time compilation process.
If you did .NET work or played with challenges such as
the FireEye challenge ..(audio blipped).. to recover
keys, you can just throw something into an ILD compiler
and look at a higher level C sharp source code
experience because of how easy it is to generate C
sharp back from IL.  You can utilize the functionality
to locate meaningful objects that you might want to
steal.  And properties of interest that you can attack
at the machine code level or the just in time level.
     There is debugging functionally in here.  I'm
giving you the address of constructors and the address
of methods that you're interested in.  You can take
those and throw them in a debuger and breakpoint them.
In the case of the fingerprint reader, I have no idea
what triggered that object to appear on the managed
heap.  So I -- until something happened.  If I didn't
do that, I would have never figured it out.  This is
useful if you have time and you want to say this
application, I won't to upon it.
     This is a DLL, you can utilize something like DLL
hijacking and put this gray frost DLL on disk and every
time that application spins up ..(audio blipped).. you
don't have to worry about things like attacking the
just in time compiler because it does it the second is
loaded.  Every time a SQL object appears on the heap I
want to grab it.  You can do this by placing a
[indiscernible] and every single object on the managed
heap is yours.
     Opens up a whole new avenue of hybridization.  A
lot of what I did when I manipulate the managed heap is
calling into raw machine code to pars all of those
structures.  So you can now utilize this technique to
do even more complicated things that haven't been
possible before.  You can also do things because we're
at a higher level coding space, then say C or machine
code in that it's incredibly easy to use crypto
libraries.  Encrypt the -- within gray frost or the
payload.  Call off the web server and make something
superhard -- how easy it is to reverse .NET.  Give them
hell.  You can do this at the machine code level.
Encrypt it, do some sophisticated hackery techniques to
make it hard to find you and fire the payload.
     And then the payload system, why use it.  For
starters C sharp is an incredibly easy language to
learn.  None of these guys really understood the power
of reflection or there were pointers in the .NET
framework.  It has easy to use C sharp and easy to
build payloads and malware in C sharp.  Because of
these techniques and the gray frost platform you can
run this in any application you want.  Because the gray
frost DLL creates or injects the 4.0CLR you can inject
this thing into a python application and spin up the
.NET framework inside that.  You may want to do that
but the really purpose is attacking .NET but that is
cool and would blow somebody's mind.
     The low and high level gap is relatively easy.
..(audio blipped).. people that code in C sharp and in
assembly can drink beer together and be friends instead
of hate each other.  Which I think is cool.
     You should get involved with this .NET hacking
space and read the code and contribute to it.  It's
really small now.  In the research I did, there were
hardly any tools that were reference able.  Nobody was
attacking the managed heap.  And most -- attacking
world of warcraft which on some of these forms people
with getting owned and pissed off and rage quitting
because they invest in security.  And there are lots of
PowerShell which is a subset of .NET.  It's cool and
powerful but I think this has good practicality if you
want to get into this.
     A lot of this was inspired by previous DEFCON
talks.  Especially 18 and 19.  I have shown you that
arbitrary .NET applications can be injected and changed
at run time and open up another avenue for .NET
possibilities.  These tools support automation and
they're on GitHub, ask me questions.  If you do have
questions you can come up here afterwards.  I am around
until tomorrow.  I am dumb and got bad flights.  You
can check in on Twitter.  Thank you for listening.