Friday 27 July 2012

CounterHeapSpray monitors the private memory usage of an application to guard against heap sprays. When the private memory usage of the application exceeds a predefined threshold, CounterHeapSpray assumes that a heap spray is ongoing and will pre-allocate virtual memory pages and populate these pages with its own shellcode. When the heap spray terminates and the exploit executes, code execution will transfer to CounterHeapSpray’s own shellcode. This shellcode will suspend all threads and display a warning message for the user. When the user clicks OK, CounterHeapSpray’s shellcode terminates the application.
By planting its own shellcode before the heap spray can fill the heap with malicious shellcode, CounterHeapSpray not only prevents execution of this malicious shellcode but is able to suspend the process and to inform the user of the attack.

Monday 14 May 2012

Now I’ve added the asm files (sc-ep.asm for 32-bit and sc-64-ep.asm for 64-bit) for this shellcode to my library.

Remark that the 32-bit version assembler code, that was generated with my simple shellcode generator, has a ret instruction after the call to ExitProcess. This instruction will never be executed, as a call to ExitProcess does not return.

Tuesday 1 May 2012

My TaskManager spreadsheet provides you with a couple of commands to terminate (malicious) programs. But sometimes these commands can’t terminate a process (for various reasons).

Today I’m adding a new command to our toolkit: injecting and executing shellcode in the target process. I’m providing 32-bit and 64-bit shellcode that calls ExitProcess. When this shellcode is injected and executed inside a process, the process will terminate itself.

Here I’m using the command “e ep64”: this command injects and executes the shellcode found in sheet ep64 (as hex strings) in process notepad:

The result is that notepad will terminate itself.

When using TaskManager on a 64-bit system, you’ll have to pay attention to the following: to terminate a 32-bit process, you inject 32-bit shellcode (ep32) and for a 64-bit process, you use 64-bit shellcode (ep64). And a 32-bit process can’t access a 64-bit process’ memory through the Windows API, so if you are using 32-bit Excel on a 64-bit machine, you won’t be able to inject shellcode into 64-bit processes.

FYI: If you want to know more about 32-bit and 64-bit processes on x64 Windows, I’ll bedoing a workshop at Brucon this year: “Windows x64: The Essentials”.

Here’s what I changed exactly from the original MASM code:
1) non-volatile registers are preserved (by storing them on the stack)
2) building the DLL name for forwarded functions is done with a variable on the stack frame of lookup_api, and not of the caller
3) the address of LoadLibraryA is passed via r9, and no longer r15
4) lookup_api not only returns the function address in rax, but also stores it in memory at an address provided in r8
5) fixed the error handling bug (stack restoration)
6) added some EQUs to make it easier to use this code as a “library” (include)

You can get the code from my shellcode page. Look for filenames starting with sc-x64 in the zip file.