Failed on Windows 10.0.18362 about sweetpotato HOT 13 CLOSED

By the way .RoguewinRM v1.1 works on the testing windows 10 1903 x64 @CCob

from sweetpotato.

Is anything already listening on port 5985 like WinRM?

from sweetpotato.

Is anything already listening on port 5985 like WinRM?

No, nothing is listening on 5985.

from sweetpotato.

The other possibility is BITS was already running. BITS only attempts to connect to WinRM on startup, so if the BITS service is already started due to an ongoing download or a recent COM invocation of BITS, this is another reason it wont work.

If that is also untrue for your situation I'd suggest adding debug code into the WinRM connection thread to see if you do get a connection from BITS at least.

As for me here on 1903 it works fine, so hard to debug.

from sweetpotato.

The other possibility is BITS was already running. BITS only attempts to connect to WinRM on startup, so if the BITS service is already started due to an ongoing download or a recent COM invocation of BITS, this is another reason it wont work.

If that is also untrue for your situation I'd suggest adding debug code into the WinRM connection thread to see if you do get a connection from BITS at least.

As for me here on 1903 it works fine, so hard to debug.

I stopped the BITS and run it get below errors:

SweetPotato by @_EthicalChaos_
  Orignal RottenPotato code and exploit by @foxglovesec
  Weaponized JuciyPotato by @decoder_it and @Guitro along with BITS WinRM discovery

[=] Your version of Windows fixes DCOM interception forcing BITS to perform WinRM intercept
[+] Attempting NTLM Auth with CLID 4991D34B-80A1-4291-83B6-3328366B9097 on port 5985 using method Token to launch c:\Windows\System32\cmd.exe
[!] No authenticated interception took place, exploit failed

Unhandled Exception: System.ArgumentNullException: Value cannot be null.
Parameter name: s
   at System.Convert.FromBase64String(String s)
   at SweetPotato.PotatoAPI.WinRMListener()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.ThreadHelper.ThreadStart()

from sweetpotato.

Hmm, that's a strange one. Here is the likely offending line.

https://github.com/CCob/SweetPotato/blob/master/PotatoAPI.cs#L93

Which means that the authentication header was either not set, or the regular expression for extracting it is buggy is some situations. But unless I can get a packet capture using wireshark on loopback when you get the exception above I cant see what the problem is.

Thanks

from sweetpotato.

https://drive.google.com/open?id=1PZes-CBdvvjASWmBxsZNiUs6FvYY_dDi
This is the loopback packet I get while the exception happend.

from sweetpotato.

Can you try issue3 branch? I've added some additional debugging logic to LocalNegotiator. This appears to be failing on your pcap sample.

from sweetpotato.

Can you try issue3 branch? I've added some additional debugging logic to LocalNegotiator. This appears to be failing on your pcap sample.

The output:

SweetPotato by @_EthicalChaos_
  Orignal RottenPotato code and exploit by @foxglovesec
  Weaponized JuciyPotato by @decoder_it and @Guitro along with BITS WinRM discovery

[=] Your version of Windows fixes DCOM interception forcing BITS to perform WinRM intercept
[+] Attempting NTLM Auth with CLID 4991D34B-80A1-4291-83B6-3328366B9097 on port 5985 using method Token to launch c:\Windows\System32\cmd.exe
Error 590610 result from AcceptSecurityContext
Failed to handle type SPNEGO[!] No authenticated interception took place, exploit failed

The pcap:
https://drive.google.com/open?id=1oPqeUGChLx9Tr66ak3c8nPgZeO6QdbEs

from sweetpotato.

Thanks. I've pushed some additional changes to the issue3 branch. Can you try again? Out of interest, is the machine domain joined? So far I've only tested on non domain joined machines.

from sweetpotato.

@CCob This time It works. Good job!!!

from sweetpotato.

Nice, looks like the security buffer wasn't large enough to hold challenge response in your environment. I'll get this merged back into master. Thanks for your help debugging.

from sweetpotato.

Merged into master, so closing.

from sweetpotato.