Thank you for your tool, NTLM endpoints are (still) overlooked and underrated!
In a recent real-world test I ran into a false negative case where /adfs/services/trust/2005/windowstransport was reported by the tool as not there. However upon manual testing, /adfs/services/trust/2005/windowstransport was indeed present and I was able to successfully do all the fun things thereafter.
On https://github.com/nyxgeek/ntlmscan/blob/master/ntlmscan.py#L69, requests.head is made. However, when I changed this to a GET request (requests.get), the /adfs/services/trust/2005/windowstransport endpoint was properly discovered.
I don't have the exact reason this happened, but perhaps IIS/ADFS can behave differently for HEAD vs GET on certain endpoints. It's possible that IIS handler mappings only fire authentication challenges on verbs that would actually serve content?
Either way, would there be a downside to swapping from HEAD to GET to eliminate false negatives in these cases?
Thank you for your tool, NTLM endpoints are (still) overlooked and underrated!
In a recent real-world test I ran into a false negative case where
/adfs/services/trust/2005/windowstransportwas reported by the tool as not there. However upon manual testing,/adfs/services/trust/2005/windowstransportwas indeed present and I was able to successfully do all the fun things thereafter.On https://github.com/nyxgeek/ntlmscan/blob/master/ntlmscan.py#L69,
requests.headis made. However, when I changed this to a GET request (requests.get), the/adfs/services/trust/2005/windowstransportendpoint was properly discovered.I don't have the exact reason this happened, but perhaps IIS/ADFS can behave differently for HEAD vs GET on certain endpoints. It's possible that IIS handler mappings only fire authentication challenges on verbs that would actually serve content?
Either way, would there be a downside to swapping from HEAD to GET to eliminate false negatives in these cases?