@monoxgas - Nick Landers
When supplying a logon buffer to LsaLogonUser, there exists many "Unlock" variants of the base structures.
These variants include an additional LUID which is used to indicate the original logon session you intend to "replace" during this unlock.
2/
@monoxgas - Nick Landers
In the case of a Kerberos unlock, once the logon is complete a call is triggered to KerbUpdateOldLogonSession with the supplied LUID. Up until now, no validation has been performed on this value.
3/
@monoxgas - Nick Landers
Underneath KerbUpdateOldLogonSession decides whether the supplied LUID is valid by simply comparing the domain and username between the sessions.
If they match, it will copy all credential materials (passwords, tickets, etc.) from the new session to the old.
4/
@monoxgas - Nick Landers
So what happens if we pass the well-known SYSTEM LUID during an unlock and trick Kerberos into believing our new session username is the computer name?
Kerberos will happily replace the machine account pw with our user pw and we can now forge arbitrary Silver Tickets!
5/
@monoxgas - Nick Landers
"How would we pull of this trick" you ask?
We can use pinning to intercept the AS-REP on the way back from the DC and swap out the username in the ticket. Kerberos will notice the discrepancy, and assume the ticket contains the true username for the session.
6/
