Seasoned Metasploit Framework users know that it’s a bad idea to let the framework generate an executable for you.
The framework’s encoders are not a tool to get past anti-virus. By happy accident, an encoded payload would get past some anti-virus products, but that was four or five years ago. If the Metasploit Framework generates an executable for you–it will get caught.
What’s an aspiring hacker to do? Fortunately, Metasploit Framework modules that generate executables expose an option, EXE::Custom. If you set this option to your own executable the module will use it, instead of generating an executable that will get caught.
This is a good time to become familiar with a tool or framework to generate executables. The Veil Framework is a good option.
For most modules, EXE::Custom is as simple as I’ve described here. Provide your own executable and enjoy freedom from detection. That said, there are two cases where you need to pay special attention to the file you provide.
psexec
The windows/smb/psexec module will generate an executable, copy it to a target, and create a service to run it. There’s two caveats for this executable.
When you run an executable as a service, it must respond to commands from the Service Control Manager. If you provide a normal executable, Windows will automatically kill it for you and you will not get your session.
Also, beware that the PsExec module will create a service, start it, and immediately try to stop it. The module will appear to hang until the stop operation completes. This has an implication for the design of your executable. To behave as this module expects–your service executable should start another program and inject your payload into that. If you do not pay attention to this detail, you may notice that your payload will appear to die after 30 to 60 seconds. The service stop operation will force kill your program after a grace period.
Check out the source to the Metasploit Framework’s version of this executable.
bypassuac_injection
One of my favorite privilege escalation options is the UAC bypass. The Metasploit Framework’s bypassuac attack takes advantage of a loophole to write a malicious DLL to c:\windows\system32\sysprep. It then launches sysprep.exe which will load the malicious DLL. This gives us elevation because sysprep.exe automatically starts itself in a high integrity (read: privileged) context.
In early 2014, Meatballs created a variant of this attack that touches disk only when necessary. This is the bypassuac_injection module.
This module also accepts an EXE::Custom option. Do not be fooled. This option does not accept an Executable. It expects a DLL. This is the malicious DLL that sysprep.exe will load.
You want to make your custom UAC DLL spawn a new process, inject your payload into it, and immediately cause the current program [sysprep.exe] to exit. This is the least disruptive experience for the desktop user. If your target is a 64-bit system, make sure you provide a 64-bit DLL.
Check out the source to the Metasploit Framework’s version of this DLL. [Note: If you read this DLL’s source code, at first read, it will look like the current program doesn’t exit. It does. When the Metasploit Framework populates the compiled DLL template, it adds code to exit the current process.]