Why 0x01 should understand Windows Security Authentication mechanism:
Deepen the depth of understanding of subsequent exploits, or that sentence, to know it, but also to know its why, not nonsense, we directly began
0x02 Windows authentication protocol mainly has the following two kinds:
NTLM-based authentication, mainly used in the early Windows Workgroup environment, the certification process is relatively simple
The other is based on the Kerberos authentication method, mainly used in the domain environment, the following two different authentication methods to do some brief communication process description
0X03 A brief description of the NTLM certification process, as follows:
0x04 we can clearly see that the authentication process of NTLM in the domain is divided into the following steps:
first, first in the client input username,password and domain, then the client will be password hash value first cached to the local second step, after that, the client sends the username clear text to the server ( DC) The third step, the DC will generate a 16-byte random number, that is, Challenge (Challenge Code), and then pass back to the fourth step of the client, when the client receives challenge, will first copy out, and then with the password hash in the cache to mix hash again, After the mixed value is called response, and then the client will challenge,response and username together to the server fifth, the server side after receiving the client passed these three values will be forwarded to DC sixth step, When the DC received these three values, will be based on the username to the domain control of the account Database (Ntds.dit) to find the username corresponding hash, and then this hash out and pass over the challenge value of mixed hash seventh step, will ( 6) after mixing the hash value with the response to compare, the same authentication succeeds, conversely, the failure, of course, if it is a local login, all verification must also be directly in the local
0x05 a little summary of NTLM:
It is a challenge (challenge)/Response (response) Message interaction mode of authentication process, from the entire certification process, security is really not in place, that is, the intruder only need to get a system administrator's hash, directly to the DC certification is good, Anyway, the account name and domain name are known, the early pass the hash (psexec) is really through this way, if the local Administrator account password is the same, in fact, no password can be certified, we have to do is to continue to try to expand the network of other machines in this way, Until the whole domain was controlled, but later the kb2871997 seemed to change some status, but it might just seem
0x06 Some overview of Kerberos:
Kerberos is more complex to authenticate than NTLM because it provides a centralized authentication method that involves a total of three parties throughout the certification process: The client, the server, and the KDC [Keydistribution Center Key Distribution centre], In a Windows domain environment, the role of the KDC is assumed by a DC (domain controller[), which is a ticket-based authentication method, and the ticket (Ticket) is used to securely pass the user's identity between the authentication server and the service requested by the user. Some additional information is also passed to ensure that the user using ticket must be the user specified in the ticket, ticket once generated, can be used multiple times by the client in the lifetime to apply for the same Server service (ticket theft problem)
0x07kerberos's General Workflow:
In this case, we can probably understand that when a client in a domain wants to access a server resource in the same domain, it needs to first purchase the service-side-approved ticket, that is, the client needs to buy a ticket before accessing the server, waiting for the service ticket to enter, but this ticket cannot be purchased directly A warrant is also required, that is, the client needs to obtain a pre-purchase warrant before buying a ticket, the warrant and the entry ticket to the server are sold by the KDC, as follows:
1first, the client will hash the password of the domain user once and save it, and then use this hash as the long-term shared key between the client and the KDC [KC] (of course, the same hash is stored on the DC)2), the client starts using (1) in the domain user password hash and then the timestamp, CLIENTID,TGS ID and other information mixed hash once, and then to the as (authentication server [authentication server]) server to make the request3As received by the request, the long-term shared key (KC) is decrypted, and after the decryption succeeds, it returns two tickets to the client (1) encrypted K (C,TGS) (for client-side subsequent requests to KDC), TGS name/ID, timestamp, etc., the ticket is encrypted by KC (2) A ticket- granting Note (Ticket granting Ticket, or TGT), which is to the TGS, the contents of which include K (C,TGS), client identity information, domain name, timestamp, etc., which are encrypted by the TGS's secret key and only the TGS can decrypt 4The client then decrypts K (C,TGS) with a long-term shared key and uses the key encryption to generate a authenticator that includes: lifetime, timestamp, client identity, and so on, together with the TGT obtained from as and sent to the TGS 5The TGS uses its own secret key to decrypt the TGT, gets K (C,TGS), and uses K (C,TGS) to decrypt the authenticator sent by the client, authenticates the clients, and if the client passes the authentication, the TGS randomly generates a session Key K (C,s), and produces two notes (1Service Ticket (Ts): This is the service ticket to the server, encrypted by the server key KS, including: K (c,s), client identity information, service ID, timestamp, lifetime, etc. (2) client Ticket (TC): The ticket is encrypted by K (C,TGS) and includes: K (c,s), server identity information, etc.6after receiving a response from the TGS, the client uses K (C,TGS) to decrypt the TC, obtain K (c,s), server identity information, and so on, and use K (c,s) encryption to generate a authenticator sent to the server, including: timestamp, Client ID and other information, along with TS One, to the server7Server side after receiving the client request, the use of their own key KS decrypt TS, get K (c,s), and then use K (c,s) decryption authenticator, the client authentication, if the certification passed, it means that the KDC has allowed the communication, The sever does not need to communicate with the KDC at this time because the KS is a long-term shared secret between the KDC and sever, and if within the valid time, the request is valid
0X08 about the Kerberos utilization method:
1) Gold Bill (Golden Ticket)
First of all, assuming such a situation, the original has been received in the domain of all the account hash, including krbtgt this account, due to some reasons caused by the loss of domain control, but fortunately you also have a normal domain user rights, it happens that the administrator in the domain when the reinforcement forgot to reset the krbtgt password, based on this condition, We can also use the ticket to regain domain administrator privileges, using KRBTGT hash value can be forged to generate arbitrary TGT (Mimikatz), can bypass the account policy of any user, let the user become a member of any group, can be used for Kerberos authentication of any service
2) Silver Bill (Ticket)
By observing the authentication process of the Kerberos protocol it is not difficult to find out if we have obtained the server key KS (password hash value), we can skip the KDC authentication, directly forge the ticket and target server communication
0x09 Some differences about gold notes and silver notes:
1) Different access rights
Golden Ticket: Forge TGT, can get any Kerberos service permissions Silver Ticket: Forge TGS, only access specified services
2) different encryption methods
Golden Ticket by Kerberos hash encryption silver Ticket by service account (usually computer account) hash encryption
3) certification process is different
The use of Golden Ticket requires access to domain control, while the silver Ticket does not require
Summary:
These are in fact the domain of the most basic knowledge of infiltration, so I think we still very need to spend a little more time, a good deep experience, in addition, Microsoft gave us the advice is to try not to use NTLM directly, and use negotiate, if using negotiate, Windows will first determine if Kerberos is available and use Kerberos if available, otherwise the security of Ntlm,kerberos is really much higher than NTLM.
Further detailed Windows security authentication mechanism Ntlm&kerberos