Guest post by @infosecsmith2
There was a recent presentation at DerbyCon, entitled:
Living Off the Land: A Minimalist’s Guide to Windows Post-Exploitation by Christopher Campbell & Matthew Graeber
I highly recommend that you start with this presentation as it lays the foundation for this post.
The premise is, how can we maintain persistence in a corporate environment, using tools and defaults provided by the host OS we have compromised. This is a very important concept, given the shift in many organizations to an Application Whitelisting Defense model.
It is only a matter of time before time before you might encounter an Application Whitelisting Defense.
As a follow up to that presentation, I began exploring the binaries that ship by default with Windows. That is where I stumbled across a binary in the C:\Windows\Microsoft.NET\Framework64\v2.0.50727 path.
The Executable is ieexec.exe. A write up is here: http://support.microsoft.com/kb/822485
“The IEExec.exe application is an undocumented Microsoft .NET Framework application that is included with the .NET Framework. You can use the IEExec.exe application as a host to run other managed applications that you start by using a URL.”
Excellent! So, now we just need to host our malicious binary , and call it from ieexec.exe.
This is great, since most Application Whitelisting Environments are going to “Trust” anything signed my Microsoft as a matter of convenience. IEexec.exe will download and execute our code for us, all under the trusted process.
So lets get started!
Step 1. Prepare your Shellcode, or whatever malicious app you want. I compiled my executable using SharpDevelop, since it has less footprint than a full blown Visual Studio install. From msfconsole:
1 2 3 4 5 6 7 8 |
|
Step 2. Create the .NET wrapper application
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 |
|
You will want to compile the exe for the target platform. In this case I am going for an x64 target. Also, you will want to compile for 2.0 or 3.5 Framework.
Step 3. Host the Exe. For this example, I used Mongoose. Simple and Effective:
http://code.google.com/p/mongoose/
By default Mongoose listens on port 8080. This is configurable. Simple place your compiled binary from step 2 into the same directory as Mongoose. Start Mongoose and you are almost ready to deliver your payload.
Step 4. Setup your receiver:
1 2 3 4 5 |
|
Step 5. From the host that is protected via Whitelisting. Open 2 Command Prompts as administrator.
CMD 1 Execute:
1
|
|
 CMD 2 Execute:
1
|
|
There is some detail to unpack here, I can go over later, as to why we need to run caspol.exe. Here’s the behavior I saw in our experimentation with this.
Initial attempt to run our rogue binary fails, since it is unknown/untrusted/unapproved:
Now, on the same host…
Executes just fine!
Its important to distinguish what this technique is and what it is not. This is not an exploit or vulnerability. Rather this is one way to execute arbitraty code in an Application Whitelisting Environment.
Summary:
In this document we learned that even if a host is in a mode where only trusted approved applications can run. IEexec.exe can be used in certain situations to circumvent a Whitelist, since it is likely a trusted binary, since it is signed by Microsoft.
Cheers,