Open c0d3z3r0 opened 3 years ago
I ran into this exact issue yesterday and investigated a little further. Note that i have basically no clue about NTLM internals, but thats at least how I think what fails. But maybe it helps to narrow down the issue.
Starting with the actual error: The script reads the server name from the ntlm part of the NTLMAuthChallengeResponse()
:
authenticateMessage = NTLMAuthChallengeResponse()
[...]
av_pairs = authenticateMessage['ntlm'][44:]
av_pairs = AV_PAIRS(av_pairs)
While the in provided pcap in the original blogpost this field is filled with further NTLM related data (server name, domain etc, which is also provided in the "parent" structure of the packet), in my case this ntlm data is filled with the checksum (?) of 24 bytes only. Hence the index 44 can't be read and crashes the script.
I tried to investigate why the DC i used the printerbug on authenticates to my relay server, but does not provide this additional information, but failed to do so. Maybe the DC is configured in such a way that the printer bug is fixed, e.g. that the DC connects to the relay but does not provide the nessecary additional ntlm data. When i tried to hardcode the server name (which is the only value read from this missing structure), the exploit failed at a later stage.
Hey @c0d3z3r0
A network trace would be appreciated to take a look at the NTLM blob and reproduce this issue.
I'm having this same issue while doing a HTB lab. I get the same result whether I use dementor.py or printerbug.py. I've tried multiple commits of impacket, and I'm still getting the same issue.
Did you ever get this to work?
Same problem here. Can we provide additional information so this can get fixed?
Same problem here. After a bit investigation, it actually caused by upper-level code threw a ACCESS_DENIED error code and not being handled correctly, thus being taken as integer in this level of code. But the root cause is still pending for analysis.
This could be stably reproduced in HTB lab while trying to exploit PrinterBug via (Dementor & NTLMRelayX for DCSYNC) on Kali Linux with a valid credential.
update: after a few respawn of lab targets, this program works smoothly, I suspect the problem may caused by incomplete configuration of software or network glitch.
Same issue is still present it seems, vulnerability was reported as present both with Metasploit, Nessus, PingCastle and PurpleKnight tools however relaying failed with the error mentioned above.
Configuration
impacket version: current master Python version: 3.8 Target OS: Kali Rolling
Debug Output With Command String
This gets triggered after running the printerbug script from krbrelax:
PCAP
If applicable, add a packet capture to help explain your problem.
Additional context
Space for additional context, investigative results, suspected issue.