Adding Shadow Credentials attack to ntlmrelayx

[ShutdownRepo]

Added PyWhisker's add feature to ntlmrelayx.
More info on The Hacker Recipes

This PR is a duplicate to #1132 which I messed because I don't know how to git properly...
Co-authored by @Tw1sm @nodauf @p0dalirius

[SAERXCIT]

Hi !

I haven't actually tried it, but I think the target auto-select feature (in case no target has been configured as a CLI argument) will work for the first relay, but won't for any subsequent one.

https://github.com/SecureAuthCorp/impacket/pull/1249/files#diff-f5a8586ba03df118d0247b126099c2419a83e10be65779f19ea67ef19072a067R246

In this line the global self.config.ShadowCredentialsTarget variable gets overridden with the username of the first target that will be relayed. As such, it will keep this value for the rest of the execution of ntlmrelayx, including all further relays performed with potentially different targets.

If a different target gets relayed afterwards, the previous check if not self.config.ShadowCredentialsTarget will evaluate to False as the variable will have been overridden in the previous relay, and the target will not be updated. The attack will continue with the new relayed user trying to perform the attack on the previously relayed target, which will most likely result in failure.

If this is actually what happens, I suggest using a temporary variable to store the current relay target for the current relay and replacing all instances of self.config.ShadowCredentialsTarget with this variable, as I did in this commit because at first I had made the same mistake in my code 🙃

Also, I guess the check if self.config.ShadowCredentialsTarget in delegatePerformed should be performed afterwards, and on this new temporary variable, else it will be ineffective as self.config.ShadowCredentialsTarget will not be updated with the actual target.

Cheers !

[ShutdownRepo]

Hey you might be right there! @nodauf implemented this changed and is the best suited to operate the changes if needed in my opinion. @nodauf what do you think about this?

[nodauf]

@SAERXCIT Yes, you are absolutely right. Thank you for the explanation. I will push the fix asap.

[joshdodger197]

Why not integrate this with Adam's interactive LDAP client? That way this could be one of several great LDAP options and you can do some enumeration of where the object that you've managed to relay has permissions, instead of that "one-and-done" type approach.

Either way, great addition.

[ShutdownRepo]

Hey there, that's a great idea @joshdodger197 ! In my opinion having both options would be better. This PR would allow relayed sessions to automatically attempt shadowcreds without requiring the attacker's interaction (useful when lots of sessions are relayed). The LDAP client option would be awesome too in some situations.
The link you gave is dead, can you update so I can take a look and see how the two ideas can coexist?

[joshdodger197]

Hey there, that's a great idea @joshdodger197 ! In my opinion having both options would be better. This PR would allow relayed sessions to automatically attempt shadowcreds without requiring the attacker's interaction (useful when lots of sessions are relayed). The LDAP client option would be awesome too in some situations. The link you gave is dead, can you update so I can take a look and see how the two ideas can coexist?

I can see the immediate relay for shadow creds being useful in some situations, but having the ability to do some enumeration on the session you've relayed and make your choice from there I think would be too valuable an opportunity to pass up!

More info:
#1076
https://www.praetorian.com/blog/how-to-exploit-active-directory-acl-attack-paths-through-ldap-relaying-attacks/

[0xdeaddood]

Just merged! Thanks @ShutdownRepo!