I have been seeing more and more shellcode written in high level languages lately. This last week alone i think I have seen about 5 distinct samples.
The only public hll shellcode templates i have found for Windows are one by didier stevens, and one called WishMaster.
What i am seeing falls into the following catagories:
Shellcodized C used in process injection payloads. ThreadStart argument is a prebuilt api table for the payload to use. To analyze these, I had to update the patchgen.exe so that you could also control the initial register state.
Shellcode stub that links to a C obj file. In these payloads the asm author has just decided to use certain hll functions such as an encryption library or whatever. Initilization and setup of function pointers and strings seems to still be preferred to be done in the asm stub.
single hll function extracts which use advanced or bulky WinApi. Function pointers usually passed in from asm.
I have also seen a couple which use variations on didiers template technique.
Shellcode sophistication is also on the rise, having the shellcode do more and more actions on its own. Both of these trends are only going to grow.
Multistage shellcode is also still alive and well, but everything i have seen is file format based. Extracting level 2 shellcode from the parent file and/or extracting exe payloads from the host exploit file.
Comments: (1)
On 07.04.11 - 8:20am Dave wrote:
thanks to Han for submitting another example of a hll shellcode. This one was fully written in C except for the initial decoder. It is based off of the didier template, passing a pointer to the api table into each function and using his or, shl hasher to find LoadLibrary and GetProcAddress. Strings in this sample were embedded differently though using inline asm to call overstring, pop [var_x].
This was a complex sample which mounted a sophisticated attack against AhnLab AV. It made numerous calls to the service control manager to disable services, did registry key checks, and even loads one of their dlls to call exports related to product uninstallation.
Also these attackers look like they are uploading their (encoded) malicious exes as files with image extensions to places like messagesboards or image hosting places so they can get free malware hosting. Thats pretty smart actually...