 Good morning everyone. Thank you for being here so early. I'm so glad to have this opportunity to talk with you at the DefCon Blue Team Village. My name is Yan, and my colleague's name is Siyu, but he can't be here because of his visa, so I will share it by myself this time. And I'm not good at English, so if you have any questions about this talk, it's better that we can chat face-to-face after I finish this talk. Thank you. The topic is Invaded Microsoft ATA, but you are completely exposed by the event log. So I will talk about how our team attacked AD attacks and what we have done. We are the zero key team from 360. Our team focused on web application security, testing and enterprise security. And this is our team's blog website, but there are all Chinese blogs now. I think we will read some English blogs later. Okay, the talk has six parts. The first part introduce why we do it. And the second part is the architecture we have designed to analyze the event log in real time. In the third part, we will show you some detections in detail. In the fourth part, we will show you the examples in the current program we use to detect the AD attacks. Finally, Samurai and Sans. Okay, let's go. Most enterprises are managed using Active Directory now. AD attack always occurs in the APT. Through it, the attacks can access to the important assets. So the enterprises have paid more attention to the AD security now. We need to detect advanced attacks and insider threats before they cause damage to our organization. But from the internal recon to access the AD attack covers multiple attack queue chain stages. There are many methods and tools to do the AD attack. So it's hard to distinguish the normal and abnormal behaviors. There are few tools we can use to protect our AD. Even many defenders don't know they have suffered the AD attack. First to the AD attack, the blue team is always in a passive situation. They said, I can detect AD attacks, but you can't. I have to say the Microsoft ADA. Microsoft ADA may be the most famous and the best tools to detect AD attacks. The main dictation method of ADA is to analyze the traffic through an ADA gateway or the deployed lightweight gateway directly on the DC. Additionally, it can import and analyze windows events too. Microsoft ADA can detect multiple suspicious activities and cover most of the attack queue chains. To be honest, it's the first company to achieve such a great effect. But is that all? First, the ADA is not cheap. Yeah, its price is $80 per user. I saw it on their documents that to our company, there are more than 6,000 employees in our company. It may cost about $500,000. Moreover, ADA has some limitations. They analyzed traffic manually, so we have some problems with the encrypted traffic, the unmonitored protocols and the update to detect new attacks and some bypassing and so on. So if you want to know more about ADA bypass, you can refer to this blackhead talk. So we decided to do it by ourself, although the Microsoft ADA is really great. Oh, okay. We do not use the traffic to detect attacks. The only thing we focus on is the event log of the DC. The event log records all the user activities and the object changes in Active Directory. Before we analyze the event logs, we need to turn on all the audit items in the local audit policy. So let's look at the format of the event log. There are two different parts in the event log. The first part is general information such as the system information. The second part is detailed information of changes according to different event IDs. We focus on those common IDs. You can see that different event ID represents different interesting action. Okay, this picture is an architecture we designed. We collect the event logs on all of the DCs by one log bit and then send them to the log stage. Next, log stage will save the logs to rubbish MQ. After that, the logs will be consumed to test. One is saved to elastic search. Another one is analyzed by our detection algorithm. We learn the behavior of users through logs and then generate alarms. Finally, we can see the detailed alarm data on the web console. Our architecture is very lightweight, so just install the one log bit on all DCs. There is no other impact on the dormant environment. So let's punch the intruders. Then this is an important part. According to the way of detections, we will explain this content through five kinds. The contents covers most common attacks and more detection methods are not listed because of time. The first kind, incompleted cobalt protocol. Let's review the cobalt process, which is roughly divided to three steps. The first step is the authentication service, aka AS. The user generates the password hash and send it to the KDC. After the KDC verified it successfully, the TGT is encrypted by the password hash of the content named KRB-TGT. And the final TGT is returned to the user. The second step is the ticket ground service. The user sends the TGT to the KDC. Then the KDC does not verify whether the user has permissions to the service. It only checks whether the TGT can be decrypted with the password of the content named KRB-TGT. And then use the machine password of the target service to get the ST. Finally, the user uses ST to access the target service. In the previous two steps, the AS request will trigger the 476A log and the TGS request will trigger the 476N log. So the complete covers will have both 476A and 476N logs. We can track each covers ticket requested by the event logs. So let's see the golden ticket. The TGT is encrypted using password hash of the account named KRB-TGT. Once we got this hash, we can forge any user's TGT, which is the golden ticket. Because the TGT is forged, the user does not send a corresponding AS request from the machine and there is no 476A log on the DC. And moreover, the default maximum lifetime for TGT and ST is 10 hours. So the detection idea is very obvious. When we found the 476N event log, we can search for the corresponding TGT request record according to the time of the TGT maximum lifetime. For example, we received a 476N log whose source IP is xxx.12 and the target user name is hacker. Next we need to find a 476A log from the start logs whose source IP is also xxx.12 and target user name is hacker and the time is within 10 hours. Just like the picture. If you can't find one, maybe you have been attacked by the golden ticket. Golden ticket is for the TGT, but the silver ticket is for the ST. The ST is encrypted by the password hash of the machine. If we have the machine password hash, we can forge the ST. So the attacker will not send both AS requests and there are neither 476A now, 476N logs left on the DC. So how can we detect it? The detection idea is similar to the golden ticket. When the 4624 event is triggered on the DC, we find the corresponding 476A and 476N logs. For example, we received a 4624 log whose source IP is .12. Target user name is hacker. Next we will need to find a 476N log from the start logs whose source IP is xxx.12. Target user name is hacker. If you can't find one, maybe you have been attacked by a silver ticket. You can see that it seems that we can only detect the silver ticket when attacking the DC use silver ticket. I will talk about another way to detect silver ticket in another part later. So only rely on the event log, we can't exactly link the TGT and ST according to a unique ID. I can't find such a value in the log. Currently we only rely on source IP and target user name to track the source of the ticket request. The source IP may change, causing some false positives. In theory, there is no false negative and you can reduce false positives by add some filters. Okay, the second kind log in records. In addition to the Cobras protocol introduced earlier, there is another authentication protocol in the DOMN, NTLM. Here is how we detect positive hash. Attackers can remotely access a target workstation with NTLM hash by using tools such as Mimicaz, WMIC, SMB client and so on. If a DOMN account is used to authentication, the 4776 event log will be triggered on the DC. The target account and the source workstation name are displayed in the log. Although we can't analyze the abnormal protocols like ATA to track the PTH, but we can establish a mapping of user names and workstations by recording log and event log. Each DOMN account should log into its own machine and cross-motion login behavior is not allowed. So when we found that the target user name and the computer name showing the 4776 log are not the same as the non-mapping, we need to pay attention to it. But unfortunately, we found some false positives because many people use their own DOMN account to log in a public computer. The third kind, sensitive action, includes some high-risk operations and activities that do not match the target's identity. Case one, modify ACL. ACL is a list of access control entries. The ACL determines who can access the objects in the AD and each object have a property called security descriptor which store the information about it. ACL is divided into DACL and SATL. The DACL lists the security information about who have access rights to the object and his level of access. Here we mainly focus on DACL. Okay, each ACL modification is recorded in detail in the 5136 log. The SDDL syntax is used to describe the permission information in the log. It defines the SID of the AD objects, the group ID, and the flags of the DACL. It contains a list of ACL and each ACL defines the permissions of an object. Next, let me explain how to detect ACL related attacks. CVE 2018, 8581, the popular exchange vulnerability at the beginning of the year. Attacker modifies the ACL by anti-LM relate to DC and then execute DC think. The requirement to execute DC think is to have the replicating directory changes and replicating directory changes all permissions. So the attack use the exchange account to modify the ADCL and ACL and add the permissions. To modify the ACL, we'll trigger 5136 event log. Then we can check the permissions after passing the attribute value. Monitor all 5136 events and find out that someone add abnormal account access rates to the ACL. Pay attention to the user who performs the modify operation if it's a default account like the exchange then the domain is likely have been attacked because this account rarely has active operations. Case two, detect DC shadow. It can remotely modify the object information in the domain without logging into the domain controllers. The actor stimulates the machine as a DC sending us sync request to the real domain controller. The technique is considered difficult to detect. However, the attack can be easily detected by analyzing the event log. We select two of the event logs to introduce detection. First DC shadow as the SPN to the current computer. The value is prefixed with the DRS interface GUID like E3514235.dot here. So we detect 4742 event log and check the SPN value modification of the computer account. If a special value in it and the computer is not a DC, this is a DC shadow attack. Second, we check the replication monitoring event, the fourth NAN to NAN log. If the source address is not a DC, this is also a DC shadow attack. Another one, admin privilege granted. Attacks add compromised account to some group to keep persistence. These groups are not just domain admins and administrators, but also include backup operators, DNS admins, server operators, account operators, and so on. So we need to pay attention to the following event log like this one. The member name is hacker and the target user name is domain admins. It seems that the hacker will be added to the domain admins and have the administrators privileges. Constraint delegation. Adding to account to the administrator group is too obvious and easy to find. So the attacker can access the DC by setting the constraint delegation on the target DC for the compromised account. For example, setting the value of allowed to delegate to is LDP slash DC dot defconn dot org and you can execute DC sync to DC. The detection of the constraint delegation is easy. Modify a user account where trigger four, seven, eight even log. We can check the allowed to delegate to field and find a sensitive value such as LDP, CI, FS, and our host to find the attacks. The first can honeypot account. We can create accounts with administrator privileges that contain settings which are of interest to the attackers. Those accounts don't look any different from the normal accounts, they just have the attractive permissions. The first honeypot account have attractive SPN value. Cobal Rothstein's first step is to find a service account which with a specific prefix value for SPN or admin account equal to one. The attackers attempts to request the ST using AC4 encryption and the local offline correct password. If the account has permissions, have admin administrator privileges, the attacker can quickly access. Take close attention to all activities related to the honeypot accounts such as SAM, Cobal Roth and account login and so on. If the honeypot account with SPN value of the MS SQL service prefix does not attract the attacker, set a constraint delegation with a value of LDP slash DC DEF CON organization for this account. Once the attacker corrects this honeypot account, he can got all the passwords from the account via DC sync. Well, it sounds great. The attacker can only need to request the ST and then have a cup of coffee waiting for the password to be crashed successfully. But we are waiting for them to. The third honeypot account, not required pre-auth. If setting the do not require Cobal Roth authentication, the attacker can request the TGT for offline cracking. We can turn this option on to induce attackers to request it so that we can detect malicious behaviors. Final, pay attention please. In your situation, the honeypot account will not be used. So any related logs will be triggered by the attacker. In order to prevent successful cracking, the honeypot account must set a complex password and the password length is greater than 12, no, no, no, no, 25. Also, in order to prevent catch the tickets of being taken over by other messengers, do not log in and use the account. The fifth part detects a known threat. Case one, fake account info. Each user has a unique and unchanging SID in the domain. You can query the information of account by user name or SID. When an attacker use Mimikaz to create a silver ticket, he can fill in any user and any ID parameters. This ticket is valid, but the log will record all the information. So when the attackers use silver ticket to log into the DC, the following four, six, two, four logs will be left on the DC. When the attacker randomly filled in the user name or SID, we can see that the user name and SID can't match or can't be queried. So we can use another way to detect the silver ticket when the hacker is not careful. Case two, privilege is correlation. I think it's very worth to show. The four, six, seven, two event log is triggered on the DC when the administrator logs into the DC. In other words, only the administrator's login can trigger the four, seven, four, six, seven, two event log. The subject user name and subject user SID feels show the current administrator's name and SID. So what can we do? We found something interesting. After you successfully escalate privilege with MS-1406A and you log into the DC, it will trigger four, six, seven, two event, but at this point, you are not administrator. You just forwarded a PAC and got temporary administrator privileges. So when we found the name in the four, six, seven, two log, but he is not an administrator, it must have been attacked. More than MS-1406A, there may be other ways to escalate privilege in the future. As long as it is a temporary privilege, escalate privilege in the future, it must not escape this detection. At the last multi-tections, we can detection the core hosting AS requested just by monitoring the value of ticket encryption type in four, seven, six, eight and four, seven, six, nine event log. We can recognize the attacker's tools by monitoring the value of ticket options in four, seven, six, eight and four, seven, six, nine event log. There are many tricks here, but it needs a long time to describe them, so I want to talk about these tricks and many other detections in detail this time. If you are interested in them, I can show you after I finish the talk. Achievements here, there are some videos. It's so sorry that it only have the Chinese version. So the first one is easy. It's an example that we detect the admin group enumeration. We executed the net group domain admin slash domain account or comment, open our web console. We detect it, it shows that someone enumerated the domain admin group using the account named test user one. Okay, this is an example that we detect the golden ticket attack. We use the mini cards to create golden ticket and then use it, just wait. Okay, then we detect it, it shows that the computer one is requesting the ST and never requested a TGT. So we regard it as a golden ticket attack. We can also get detailed information on the web console. Okay, this is an example of DC shadow. We also use the mini card to do the DC shadow attack. Okay, we detect that the computer zero to simulate the domain controller zero one with privileges of exchange, the account exchange zero one because it has modified the value of computer zero to SPN value to the abnormal value. Okay, the last and complex one, CVE 2018 and 8581. We use the tools to relay the exchange NTIM hash to the DC and modify the ACL with moment. It needs some time. No, no, no, no, no, no, no. Okay, succeed. Here, we will find the NTIM of the computer zero two which is exchange server has been related to the DC zero one. It can show the detailed information of the machine and the user. Then the exchange server modified the ACL. You can see the new alarm in the abnormal ACL modification. We detect it successfully. At the last conclusion, there are some limitations with event log first. There are some false positives in the detection of lateral movement. But if you can collect local event logs, you can detect lateral movement attacks more exactly. Second, if the attack methods do not trigger the event logs on DC, we cannot detect them such as elevation to DA from DNS admin memberships attacking circle server, pass the hash with local account searching info by LDAP and so on. Although there are some limitations, I think it's worth to do it. We only do the DC event log analysis. It's lightweight and easy to deploy. And we have finished about 36 kinds of alarms belong to different future stages. We can detect most persistence attacks by analyzing event logs such as admin SD holder, DSRM, group of policy, DC shadow, SID history, Modify ACL and so on. So in a word, the process of attack generates traffic and the result of the attack is event log. Our analysis is based on the results of the attack, which is less likely to be bypassed or confused than the process analysis. So I think if you have known the attack methods, you can build your own ADA by analyzing event logs. It's not very hard. Okay, that's all. It's hard to do the Q&A directly for me. So if you have any questions, we can chat face to face. You can also directly message us via Twitter or email. Okay, thank you, thank you all.