Spooky authentication at a distance

1. Introduction to common windows authentication types SPNEGO/NTLM/KERBEROS
   • NTLM - the old and bad
   • KERBEROS - the old but good
   • SPNEGO to glue them together
2. Brief description on Windows integrated authentication (SSPI)
   • high level explanation of the logic
     • your passwords are still stored (but it gets harder to get them)
     • you dont need the passwords/secrets during an attack, you just want to USE them. This is what SSPI is for.
   • actual API calls representing the logic
     • the short-named calls (Acquirecredentialscontext and InitializeSecurityContext)
     • the ones that SEAL the deal (EncryptMessage and DecryptMessage)
     • the one that breaks everything (QueryContextAttributes)
3. How is SSPI used daily
   • Specific case: LDAP authentication
     • Authentication/encryption conforms to standards
   • Specific case: SMB authentication
     • Authentication/encryption is different because why not
     • But wait, it’s still SSPI
4. The problem starts with…
   • Overview how the complete communication flow looks like in SMB. Using this chart the audience can see how we move the the building blocks of networking and authentication away from the corporate computer to an attacker controlled one.
   • Detaching network communication part from the protocol (we have socks4/5 for that! job is simple)
   • Detaching authentication from the protocol.
     • SSPI functionality implemented in Python

     • Authentication can be “relayed” in all cases (NTLM/Kerberos/SPNEGO). (flow description, NTLM version as an example) a, attacker initiates a connection via the victims socks proxy to the destination service on the internal network b, service responds to the attacker (via victim) asking for authentication c, attacker triggers authentication sequence on the victim machine, recieves the first ‘token’ d, attacker uses this ‘token’ to continue the authentication towards the server e, server asks for continuation of the authentication, sends ‘reply token’ to attacker f, attacker sends the ‘reply token’ to the victim’s authentication context to continue the authentication process, recieves another ‘reply-to-reply token’ g, attacker send this ‘reply-to-reply token’ back to the target service, finishing the authentication. server sends back ‘auth finished token’ h, attacker sends the ‘auth finished token’ to the victim’s authentication context, finalizing the authentication on both ends. i, but attacker keeps the authentication data to himself, rebuilding the context locally (pars of it will be missing, so he can’t create an encrypted channel just yet) j, attacker asks the the victim’s authentication context to provide the session key, victim releases the session key. at this point the attacker has all the information to rebuild the entire authentication process and create a secure channel to the service.

     • The virtual SSPI EncryptMessage and DecryptMessage is INDEPENDENT from the target computer’s state (after authentication), only relies on the SessionKey which be obtained via QueryContextAttributes.
5. Conclusion
   • But if we detach everything what remains on the target?
     • The networking part and the SSPI proxy part which allows the attacker to attack the domain with ZERO knowledge on the actual evironment (and no administrator credentials needed)
     • No other code needs to be deployed on the target to attack the domain since the attacker can perform unlimited authentication proxy steps on the victim.
   • We have a logic that allows an attacker to run applications (compatible with the proxy) as if they would be running on the victim’s machine.
     • SMB file downloads arrive directly to the attacker’s machine
     • attacker can browse internet VIA the corporate proxy masquarading himself as the client
     • attacker can start enumeration/attacking the domain from his own computer without knowing the victim’s credentials only using it
6. Talking big, where’s the proof? (DEMO PART)
   • I created a C2 framework that only relies this the previously described logic. Code will be made public after the talk.
   • Tools I wrote which are compatible with the C2 framework (and this authentication proxy):
     • Jackdaw (entire BloodHound rewritten in Python)
     • AIOSMB (Impacket rewritten)
     • MSLDAP (full-featued LDAP client in Python)
     • OCTOPWN (all of the above tools !BUT RUNNING IN ANY BROWSER!)

In this talk I’ll be presenting a new and innovative way to proxy common authentication protocols used in Windows environments with no elevated privileges required. This allows security professionals to perform complete impersonation of the target user on their own machine without executing any further code on the target machine besides the proxy itself.