1.　Introduction

Many organizations introduce Microsoft Windows computers as from basic office workstations to core system computers. Active Directory (AD) realizes centrally manages users, computers, and their authentications. Therefore, AD is widely used as an authentication server [1]. According to a survey [2], 97% organizations answer that AD is mission-critical to their business. Thus, AD is very useful but also tends to be abused by attackers because once attackers steal the Domain Administrator's privilege, attackers easily compromise more computer resources [3]. Some computer security incidents were observed, and the attackers compromised AD using malicious tickets such as the Golden Ticket and the Silver Ticket attacks. However, there is no universal rule to detect these malicious tickets [4]. Especially, detecting the Silver Ticket is challenging since there are no logs and traces left on the Domain Controllers, and the attackers leverage specifications of Kerberos authentication, not vulnerabilities [5].

Recently, some organizations have been migrating their AD environment to Azure Active Directory (renamed to Microsoft Entra ID on August 15, 2023; however, this paper refers to it by its name at the time of the conducted verification, Azure Active Directory). They could operate a hybrid environment that combines on-premise and cloud resources. In addition, hybrid environments are expected to be adopted by many organizations for an indefinite period while continuing to invest in ongoing IT modernization initiatives [6]. In some forms of hybrid environments, seamless single sign-on (SSSO) can be optionally used; SSSO allows the on-premise AD Kerberos Ticket to be used for authentication to some Azure services as well. According to [7], From Fortune 500 companies using Azure AD, 27% introduce SSSO. In the SSSO environment, their users can log in to the Azure services without typing their password on their browser. In such an environment, attackers can compromise the on-premise AD and abuse the Silver Ticket for not only on-premise AD but also Azure services [8].

In this research, we focus on the lifetime of authentication tickets, then propose detection methods of the Silver Ticket attacks using Domain Controller event logs and Azure AD logs that are useful for hybrid SSSO AD environments.

Hybrid SSSO and on-premise authentication mechanisms themselves are different, but there are similarities in that both use authentication tickets based on lifetime. Therefore, the proposed method is also applicable for detecting on-premise the Silver Ticket attacks.

In this paper, we differentiate terms related to AD as follows:

• ・On-premise AD: Active Directory that Active Directory Domain Service manages.
• ・Azure AD: Azure Active Directory is a cloud-based Active Directory service.
• ・Hybrid environment: AD environment that is managed by both On-premise AD and Azure AD, such as Active Directory Federation Services, Pass-Through Authentication, and Password Hash Synchronization.

1.1　Summary of Active Directory

AD is a directory service of Windows resources provided by Microsoft. A server called Domain Controller centrally manages and authenticates users and computers by active directory domain. In an on-premise AD environment, users who belong to Domain Administrators have full control of all resources in the AD domain. Therefore, attackers who intrude into the organization's network tend to target Domain Administrators to get higher privileges.

We will explain the Kerberos authentication used mainly in on-premise AD environments. In an AD environment, the Domain Controller uniformly processes the authentication of all users and computers using authentication tickets called Ticket-Granting Tickets (TGT) and Service Tickets (ST).

• ・Ticket-Granting Ticket (TGT): A ticket that proves the authenticity of the user. A user requests a TGT for the Domain Controller on its first authentication process, and the TGT is stored in the user's computer and repeatedly used until its expiration. The default lifetime is 600 minutes.
• ・Service Ticket (ST): A ticket that authorizes the use of a service within the AD environment. Upon the user of a service, the user requests an ST to the Domain Controller and uses the ticket to prove its authenticity to access the service server. The default lifetime of ST is also 600 minutes.

The flow of the Kerberos authentication upon the usage of a Windows service is as follows.

• (1)If TGT expires, a user requests a TGT to the Domain Controller.
• (2)Domain Controller provides a TGT.
• (3)If ST expires, the user sends the TGT to the Domain Controller and requests for an ST.
• (4)Domain Controller verifies the TGT and, if the authenticity of the user is confirmed, provides the ST.
• (5)The user sends the ST to the server that provides the desired service.
• (6)The server verifies if the ST is valid and provides the service.

1.2　Hybrid Environment of On-Premise AD and Azure AD

Recently, some organizations have been migrating their AD environment to Azure AD and operating hybrid environments on-premise AD and Azure AD. In hybrid environments, it is common that Domain Controllers authenticate on-premise computers, and Azure AD authenticates cloud services such as Microsoft 365, etc. The same users can be used by collaborating on-premise AD and Azure AD by the following three methods.

• (1)Active Directory Federation Services (AD FS)
• (2)Password Hash Synchronization (PHS)
• (3)Pass-Through Authentication (PTA)

In this study, we focus on the PHS and the PTA. Both of them enable users to access Azure services such as the Azure portal and Office 365 without the Azure service password using Service Tickets issued by the on-premise Domain Controller. To realize this user experience, in the PHS environment, Azure AD Connect synchronizes a user's password hash from an on-premises Domain Controller to an Azure AD. In the PTA environment, the Pass-Through Authentication agent connects to the on-premise Domain Controller and confirms the password they typed is correct.

1.2.1　Seamless Single Sign-On (SSSO)

PHS and PTA can also realize the SSSO. SSSO enables users who have authenticated by on-premise AD to access some Azure services, such as Azure portal and Office 365, without typing passwords. Fig. 1 shows the overview of the SSSO, and the following is the flow of authentication of SSSO [9].

• (1)A user accesses the Web application service that requires Azure authentication with a web browser.
• (2)if the access is the first time for the user, the request is redirected to the Azure AD sign-in page.
• (3)The user types in their user name on the Azure AD sign-in page.
• (4)Azure AD requests the Service Ticket.
• (5)The web browser requests the Service Ticket for the AZUREADSSOACC account from the Domain Controller. AZUREADSSOACC is a computer account for SSSO service [10].
• (6)Domain Controller returns the Service Ticket of AZUREADSSOACC.
• (7)The web browser forwards the Service Ticket of AZUREADSSOACC to Azure AD.
• (8)Azure AD decrypts the Kerberos ticket using the previously shared key.
• (9)If verification of the Service Ticket passes, Azure AD will complete the sign-in process.
• (10)The user is able to access the application.

2.　The Silver Ticket Attacks

AD is very useful but also tends to be leveraged by cyber attacks. Though there are various types of attacks against AD, this research focuses on the Silver Ticket attacks that are especially difficult to detect [11]. This section introduces typical attack methods leveraging the Silver Ticket.

2.1　The Silver Ticket for On-Premise AD Environment

Attackers who successfully exploit the Domain Administrator privileges tend to create a backdoor called the Golden Ticket and the Silver Ticket in order to disguise themselves as legitimate administrator accounts over a long period.

There are several detection methods for the Golden Ticket, but few methods are proposed for the Silver Ticket detection. The Silver Ticket is a Service Ticket that has a legitimate signature created by attackers. Attackers tend to create the Silver Ticket with a significantly long-term validity (e.g., ten years) for accessing specific Windows services. If attackers can get administrative privileges on the server that provides the target service, they could create the Silver Tickets for the service. The use of the Silver Ticket means that the the server and its service are under the control of the attackers, thus requiring immediate detection and appropriate measures.

2.2　The Silver Ticket for SSSO Environment

In the hybrid environment, attack methods are different depending on the target architecture. In this study, we focus on the Hybrid AD environment with PHS or PTA that provides SSSO.

In hybrid environments that integrate on-premise AD and Azure environments, various Single Sign-On features are provided for usability by Microsoft. Among them, Microsoft provides PHS and PTA that synchronize the passwords of the on-premise environment with the cloud environment. In addition, Seamless Single Sign-On (SSSO), an optional feature for PHS and PTA, uses Kerberos tickets for access to Azure as well for a more seamless login to Azure. In general, when users access Azure with a browser, they would normally need to type a password. On the other hand, in the SSSO environment, users can log in without a password once authenticated by Azure since the Kerberos ticket stored in the client computer's memory is sent to Azure. The Service Ticket for SSSO is signed and encrypted with a special account password hash called AZUREADSSOACC＄．

If attackers steal this password hash, they can create the Silver Ticket to log in to the Azure environment. Once attackers obtain the Silver Ticket, it is possible to compromise the target organizations for a long period of time without re-invading their network, which is why the Silver Ticket is frequently abused for APT attacks.

There are several ways to use Azure services. The most common uses are listed below.

• (1)Access Azure Portal or Microsoft 365 Portal with a browser
• (2)Native applications such as Microsoft Office and One Drive
• (3)Microsoft Graph

In the above cases, SSSO is available for only 1: browser case. In 2 and 3, password entry for Azure was required. In other words, attackers can access Azure Portal or Microsoft 365 Portal with a browser using the Silver Ticket for SSSO without plain text passwords. Attackers should obtain the password hash for the AZUREADSSOACC＄ account and the name of the account to be impersonated for creating the Silver Ticket, however, it is easy if attackers obtain the domain administrator privilege. After logging in to Azure Portal with a browser, the scope of exploitation depends on the impersonate account's privileges. If you can log in with an account with higher privileges, such as Global Administrator, you can use most Azure-related services illegally [12].

2.3　Attack Scenario

2.3.1　Attack Scenario 1 Attack Against SSSO Environment

An image of the attack scenario against the SSSO environment is shown as Fig. 2. The preconditions for Attack Scenario are as follows:

• ・The attackers' goal is compromise Azure AD environment rather than on-premise AD environment for a long period.
• ・The attackers have intruded into the target on-premise AD environment by exploiting some vulnerability, misconfiguration, or social engineering
• ・Target organization is a hybrid environment of on-premise AD and Azure and employs SSSO.

The attack scenario is as follows:

• (1)The attackers steal the domain administrator privilege of On-premise AD.
• (2)Create a Silver Ticket under the name of the account to be impersonated and for the Azure HTTP service.
• (3)The attackers use the Silver Ticket to compromise the Azure environment.

Note that once attackers steal credentials to create the silver ticket, attackers can create the Silver Ticket. If the target organization allows to access to the Azure AD from outside of the organization's network, attackers use the Service Ticket from anywhere.

2.3.2　Attack Scenario 2 Attack Against On-Premise Environment

An image of the attack scenario against the on-premise environment is shown as Fig. 3. The preconditions for Attack Scenario are as follows:

• ・The attackers' goal is compromise on-premise AD environment for a long period.
• ・The attackers have intruded into the target on-premise AD environment by exploiting some vulnerability, misconfiguration, or social engineering.
• ・Target organization's domain administrators access the Domain Controller with remote access tools like PsExec or wmic [13], [14] using saved credentials. This means domain administrators access to the Domain Controller without passwords using TGTs and Service Tickets loaded in their computer memory.

The attack scenario is as follows:

• (1)The attackers steal the domain administrator privilege of On-premise AD.
• (2)Create a Silver Ticket under the name of the legitimate account to be impersonated and for the CIFS service [15] which provides remote access service.
• (3)The attackers access the Domain Controller using the Silver Ticket with the same remote access tools used by legitimate domain administrators.

In this scenario, as described in subsection 2.4, attackers can access the Domain Controller as a legitimate administrative account by using the Silver Ticket as long as attackers have readability to the Domain Controller. Furthermore, detection is quite difficult if attackers use the same tools used by legitimate administrators.

2.4　Difficulties of Detecting the Silver Ticket

Usually, the detection of the Silver Ticket is challenging for the following reasons.

• ・It is difficult to differentiate access using the Silver Ticket from a legitimate user's access [16].
• ・No logs and traces are left on Domain Controllers.

In the default settings, the Service Ticket validation period is 600 minutes. Once the computer obtains the Service Ticket, the computer does not require the Service Ticket if the rest of the validation period is long enough. This behavior makes detection difficult if we use logs to detect malicious activities.

3.　Related Research

This section describes existing technologies and related research on detection and prevention methods for on-premise AD and Azure attacks.

3.1　Research on On-premise AD Environment

[5] focuses on attack methods and detection methods on the Golden Ticket and the Silver Ticket. It mentions the silver ticket attack does not involve the Domain Controller, it is harder to detect, and the silver ticket was not able to detected at all.

[17] introduces a detection method of attacks against on-premise AD. However, detection methods against the Silver Ticket are not mentioned.

[18] proposes machine learning techniques, particularly several anomaly detection algorithms, for the detection of Kerberoasting, which is a password-cracking attack against Kerberos.

[19] introduces the Silver Ticket attacks and mentions detecting the Silver Ticket is possible only on the endpoint and involves examining TGS tickets for subtle signs of manipulation.

[20] introduces attacks against Active Directory and corresponding detection methods, including the Silver Tickets. However, these detection methods are only available in specific conditions.

[11] introduces protection methods against on-premise AD attacks, including the Silver Ticket. The authors say the Silver Ticket attack is difficult to detect since all attack activity is local to the endpoint, with no communication with the Domain Controller to indicate that an attack is underway.

[21] introduces attacks against Windows based on MITER ATT&CK and corresponding security features of Windows. However, they do not mention the Silver Ticket.

3.2　Research on Azure AD Environment

Microsoft released the Azure security best practice. However, these best practices do not describe how to protect and detect the silver ticket attacks against Azure [22] [23].

[20], [24-26] introduces attack methods and detection methods leveraging ADFS called “Golden SAML attack” observed in SolarWinds. Golden SAML is a common attack method against hybrid environments in addition to the Silver Ticket, our research does not focus on Golden SAML attack since the detection method is already published.

[27] introduces attack methods against Azure AD, such as leveraging PHS, password spray, the Silver Tickets. However, they do not mention detection methods for the Silver Ticket.

4.　Proposed Method

The Silver Ticket attacks can be a big threat for both on-premise and hybrid environments. However, as mentioned in the section 3, none of the studies referred to have addressed the detection of Silver Tickets or have limited applicable conditions. Therefore, this study focuses on the detection of Silver Tickets. [20] proposes a method for detecting Silver Tickets using event logs, similar to this study. However, the detection is limited to older versions of attack tools and specific attack methods that can be bypassed. This proposal, while having prerequisites, suggests a method that can be applied under a broader range of conditions. This research focuses on the lifetime of authentication tickets and then proposes detection methods of the Silver Ticket attacks using Domain Controller event logs and Azure AD logs that are useful for hybrid SSSO AD environments.

4.1　Overview of the Proposed Method

To realize our proposed method, we change the Domain Controller settings to reduce the Service Ticket expiration time from the default 600 minutes to 10 minutes. Under these settings, we found a new Service Ticket always requested by the Domain Controller each time, regardless of the remaining Service Ticket expiration time. This behavior is not mentioned in Microsoft's official white paper. We confirmed Service Ticket requests for SSSO, PsExec, and wmic are always issued from the Domain Controller by evaluations in several testbeds. Under the above configurations, the proposed method detects the Silver Ticket attacks by finding accesses without corresponding the Service Ticket requests. This method is intended for implementation in relatively small organizations (with about several dozen accounts).

4.2　Prerequisites for the Proposed Method

The prerequisites for this method are as follows:

• ・The Domain Controller and log forwarding destination are not compromised by attackers. If the Domain Controller is compromised, it is possible to revert the ticket expiration time back to the original 600 minutes, which could lead to False Positives.
• ・The log server such as Elastic Stack is not compromised. In the proposed method, on-premises event logs are transferred to Elastic Stack as an example and matched with Azure logs. If Elastic Stack is compromised and logs are deleted, False Positives may occur. Similarly, if the Azure Portal is compromised and logs are deleted, False Negatives may arise. Both risks can be mitigated by securing the log server.
• ・Time is synchronized. The proposed method matches logs from the Domain Controller and Azure based on their timestamps. Hence it is essential that time is synchronized between the Domain Controller and the log server using technologies such as NTP.

4.3　Settings to Modify the Expiration of Tickets

To modify the expiration of a Service Ticket, the following steps need to be followed:

• (1)Launch Group Policy Management on the Domain Controller.
• (2)Navigate to the forest that includes your organization's domain, then go to Forest -> Domains -> Organization's Domain -> Group Policy Objects -> Default Domain Policy.
• (3)Right-click on the Default Domain Policy and select Edit to open the Group Policy Management Editor.
• (4)In the Group Policy Management Editor, navigate to Kerberos Policy:
• (5)Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Kerberos Policy.
• (6)In the Kerberos Policy, select Properties for the Maximum lifetime for Service Ticket and modify the ticket expiration in the “Ticket expires in” field.

4.4　Input Logs

The proposed method uses the Domain Controller's Event logs. Activities that occurred in the Windows system, such as authentication requests and process executions, are recorded as Event logs on the computer. The Event logs are a built-in Windows logging system and are divided into several categories, each of which has a unique Event ID. In the AD environment, logs related to authentication are uniformly recorded in the Domain Controller's Event logs. Table 1 shows the Event logs required to realize our proposed method. In this study the logs are transferred to the Elastic Stack to analyze logs in timely manner.

4.5　Detection Logic

We propose the detection method for a hybrid environment based on Attack Scenario 1 shown in 2.3.1, and the method for an on-premise environment based on Attack Scenario 2 shown in 2.3.2.

4.5.1　Detection Logic for Attack Scenario 1

In this scenario, we presume that Azure Portal and Microsoft 365 Portal are compromised using the Silver Tickets. If the Service Ticket expiration time is set to 10 minutes, our proposed method for the SSSO environment enables highly accurate detection of Silver Ticket abuse.

When a user accesses Azure services using a web browser by SSSO, the access is recorded in Azure Sign-in logs. At almost the same time, Event ID 4769 is always generated in the Domain Controller event log if the Service Ticket expiration time is 10 minutes. In the case of a Service Ticket using SSSO, the value of the service requester of Event ID 4769 is AZUREADSSOACC＄．Therefore, if access from the same user is recorded in the Azure Sign-in logs and Event ID 4769, it is considered Azure access in legitimate operations.

Fig. 4 shows an overview of the detection logic.

• (1)The logic searches the Azure Sign-in logs and extracts signInIdentifier and appDisplayName.
• (2)It extracts logs whose service requester is AZUREADSSOACC＄ from Event ID 4769.
• (3)If (1) occurs within 86 seconds of (2), and signInIdentifier in (1) matched with username in (2), it is judged two logs are related. Our logic counts the generated logs (1) and (2). If the number of (1) is higher than the number of (2) during the above time range, our detection logic proceeds (4).
  As an additional note, the 86-second time window, as shown in Fig. 4, is due to a maximum time lag of 85 seconds between Event ID 4769 and Azure Sign-in logs shown in Table 2. Azure logs do not include decimals in their timestamps. Therefore, decimals in Event ID 4679 timestamps were rounded off for calculations. The 86 seconds result from rounding up from the 85-second range. Given the potential for further delays, it may be advisable to consider a longer time than 86 seconds.

  

• (4)If appDisplayName in (1) matches The application names such as 'Azure Portal' and 'OfficeHome,' the logic judges that there is a high possibility of abuse of the Silver Ticket because Azure access is being performed without a request for a Service Ticket. We assume scenario that Azure Portal and Microsoft 365 Portal are compromised. Each corresponds to 'Azure Portal' and 'OfficeHome,' respectively.
  The application name depends on the services contracted by the organization. If organization has other contracted Azure services, which can be accessed through a browser using Single Sign-On to the portal site, they can add these services to the branch decision in (4). It is possible to monitor for unauthorized access. To add them, the organization must check the service name listed in the appDisplayName in the Azure Sign-in logs when logging into the service. Then incorporating this service name into the branch decision of (4).

4.5.2　Detection Logic for Attack Scenario 2

Our proposed method for the on-premise environment can detect Silver Ticket abuse for services whose Service Tickets are issued every time per access when the Service Ticket expiration is 10 minutes.

There are many Windows services, in this study, we focus on detecting attacks against the Domain Controller using PsExec or wmic, which are commonly used by attacks against AD. Fig. 5 shows an overview of the detection logic.

When a user accesses a Domain Controller using PsExec or wmic, execution of the specific processes is recorded in the Domain Controller's Event logs. However, they are legitimate tools, so it was difficult to determine whether such accesses were due to legitimate operations or the Silver Ticket's abuse. By combining the following decision logic, the Silver Ticket attacks using PsExec or wmic can be detected.

• (1)Search Event ID 4688 of Domain Controller's Event log whose “New process name” is PsExec or wmic. It means that remote access by PsExec or wmic was attempted to the Domain Controller.
• (2)Search Event ID 4769 of Domain Controller's Event log. However, the following logs, which are not related to PsExec or wmic, are excluded from the detection target.
  • ・Account names ending in “＄” because they are computer accounts
  • ・Account names beginning with MSOL_ bacause they are special accounts
  • ・Service name “krbtbt” because they often come with Service Ticket requests and could be noisy.
• (3)If (1) occurs within 1 second of (2) while sharing the same account name and service name as (2), it is judged two logs are related. Furthermore If the number of (1) is higher than the number of (2), it is likely abuse of Silver Ticket.
  As an additional note, the 1-second time window shown in Fig. 5 represents the rounding up value of the maximum time lag between Event ID 4769 and 4688 (0.18 seconds) shown in Table 3.

  

4.6　Detection System

To realize our proposed method, we constructed a detection system as shown in Fig. 6. Event Logs are stored in Elastic Stack. The Azure Sign-in logs are stored in the Azure AD environment and fetch the logs using an API called “Microsoft Graph.” Our custom Python program periodically compares the Event Logs and the Azure Sign-in logs to detect Silver Ticket abuse.

4.7　Detection Time

In this system, logs are polled periodically to review past logs. In this validation environment, polling occurs every 15 minutes, and the behavior is set to check logs from the past hour. Although the evaluation is set to poll every 15 minutes, the polling interval could be shortened if faster detection is desired. The reason for setting the log review and matching period longer than the polling cycle is that there is an average delay of about 5 minutes (99th percentile) before events occurring in Azure are logged [28]. By retrieving logs over a period longer than this delay, we ensure the logs are definitely reviewed and matched. Additionally, event logs stored on the Domain Controller are typically transferred to Elastic Stack immediately, with delays of a few seconds at most. Since this delay is significantly shorter than the time it takes for events in Azure to be logged, transfer delays to Elastic Stack are not considered in this validation.

5.　Evaluation

In this section, we will describe not only the evaluation environment and detection results, but also consider resource consumption and false detection.

5.1　Evaluation Environment

Table 4 shows OS and hardware specification for the evaluation.

The evaluation environment is a hybrid environment of on-premise AD and Azure. There are 17 unique users, with each individual assigned one account and one computer. The evaluation period is from January 12th, 2023, to March 31st, 2023. All users used Azure services several times.

5.2　Evaluation of Detection Accuracy

In this evaluation, we carried out the following attacks using the Silver Ticket ten times respectively at random times, all of which were successfully detected.

• ・Azure service access
• ・PsExec to on-premise Domain Controller
• ・wmic to on-premise Domain Controller

We also ran the tool in a real environment and found that neither False Positives nor False Negatives occurred. The detection rate is 100%. However, False Positives may occur depending on some conditions. The possibility of false detection is explained in section 5.5.

5.3　Evaluation for Resource Consumption

We evaluated the side effects on the Domain Controller's performance by changing the period of the Service Ticket. There was no significant difference in resource consumption due to differences in the Service Ticket validation period.

Table 5 shows the result when the period of the Service Ticket was 600 minutes. We calculated the average of memory and CPU usage of the Domain Controller from January 23rd, 2023, to January 25th, 2023.

Table 6 shows the result when the period of the Service Ticket was 10 minutes. We calculated the average memory and CPU usage of the Domain Controller from January 26th, 2023, to January 31st, 2023.

5.4　Evaluation for Detection Time

When transferring logs to Azure Sign-in logs with an average delay of 5 minutes and polling every 15 minutes, the attack can be detected at most 20 minutes later. In addition, the time taken by tools to search and process the logs must be considered. In this evaluation environment, the proposed method searches logs for the past an hour, and evaluations are conducted at the most concentrated access times between January 12th and March 31st, 2023. For the number of matches that fit the criteria of the proposed method, Event ID 4769 had about 80 hits, Event ID 4688 had 1 hit, and the total number of accesses to the Azure Portal and Microsoft 365 Portal was 10 in one hour. Therefore, the detection tools completed processing in about 2–3 seconds.

5.5　Discussion of False Detection Possibility

Through the evaluation, the detection rate was 100%. However, False Positives may occur depending on the timing of user operations. The conditions under which False Positives and negatives may occur are described in Table 7.

5.5.1　False Negatives for Attack Scenario 1

In Attack Scenario 1, the proposed method judges access as legitimate if the corresponding Service Ticket for AZUREADSSOACC＄ is issued. Attackers can actively request a Service Ticket with the account AZUREADSSOACC＄ to bypass the detection logic. However, there is no advantage for attackers since they should intrude the on-premise AD environment to bypass. That could be cause of leaving extra traces [29]. One of the advantages of the Silver Ticket is attackers can access the Azure service without intruding the on-premise AD environment. Therefore, this bypass is not reasonable for attackers.

5.5.2　False Negatives for Attack Scenario 2

In Attack Scenario 2, the proposed method judges access as legitimate if the corresponding Service Ticket is issued by the Domain Controller computer account. However, in Scenario 2, the attacker's goal is to compromise the on-premise environment, so it is more likely that the attackers have already intruded on the target network. If the attackers are able to compromise the user's terminal again and intentionally request the Service Ticket to the Domain Controller to generate Event ID 4769, it is theoretically possible to induce a False Negative.

5.5.3　False Positives for Attack Scenario 1

If the user logs in with the password, the Domain Controller will not generate Event ID 4769. This behavior triggers our detection logic. In other words, a False Positive occurs. However, if legitimate users always use the Service Ticket, they do not enter their password as an operational rules, the False Positive do not occur. If the operational rules are followed, this behavior could be an advantage rather than a False Positive. Azure is a cloud service, so basically, any user who knows the credentials can log in to the Azure services even their computer is not under the control of their organization. If attackers compromise the target network and obtain the domain users' credentials, attackers access the Azure services with domain users' credentials, but their activity would be detected. It is possible to manage computers using Microsoft Intune and restrict access using conditional access. For example, conditional access restricts only domain-joined computers when the “Require Domain Joined Device” option is enabled. Microsoft Intune and conditional access are included in the Azure AD Premium P1 (renamed to Microsoft Entra ID P1 on October 1, 2023) and Azure AD Premium P2 (renamed to Microsoft Entra ID P2 on October 1, 2023), but they are a paid license [30]. Our proposed method can be used to detect when a computer has not joined the Active Directory domain, even if the organization does not have such a paid license. It is expected that more and more users will access the organization's internal network and Azure services from their homes for remote work [31]. It is important to strict computers to access Azure services only domain joined computers.

5.5.4　False Positives for Attack Scenario 2

When legitimate administrators access the Domain Controller by PsExec with -u (specify the user name) and -p (specify the password) options, False Positives occur. This is because if PsExec is used with the -u and -p option, Event ID 4769 would not be generated because the Domain Controller would not receive a Service Ticket request. In that case, inquiry for the administrators is required to judge the False Positives.

5.6　Discussions of Impact When Domain Controller Unavailable

When applying this method, a Service Ticket is requested each time. Consequently, if the Domain Controller is inaccessible, it can lead to False Positives or affect the use of services that support SSSO or Kerberos authentication. However, if SSSO is unavailable, it is possible to access Azure services by entering a password. Furthermore, many Windows services can authenticate using NTLM if Kerberos authentication is unavailable [32], providing an operational contingency when NTLM is available. To assess the impact, this study accessed a Windows File Server with the Domain Controller shut down. During this test, NTLM authentication occurred in place of Kerberos authentication (Service Ticket request), confirming successful access to the file server. However, Microsoft announced a plan in 2023 to phase out NTLM authentication gradually [33]. Consequently, if NTLM authentication is eventually discontinued, services may become inaccessible when Kerberos authentication fails and cannot fallback to NTLM.

Next, we consider the operational impact of False Positives. The primary reasons for inaccessible Domain Controllers include:

• (1)The Domain Controller is down due to failures or maintenance.
• (2)The user is in a remote working situation and cannot access the Domain Controller.

For (1), it is possible to precisely identify the cause of False Positives. For (2), as mentioned in subsection 5.5.3, it implies that computers not authenticated are using Azure services, which can also serve as a means to detect undesirable security events.

6.　Scalability

6.1　Scalability of Detection Time

We assume that the organization has a significantly larger number of users and accounts. Initially 17 accounts during evaluation, we virtually scaled up tenfold to 170 accounts for the test. As we mentioned in section 5.4, Event ID 4769 had about 80 hits, Event ID 4688 had 1 hit, and the total number of accesses to the Azure Portal and Microsoft 365 Portal was 10 at the most. We also assume each logs scaled up ten times, for Elasticsearch, the search time for Event ID 4769 was 800 hits, for Event ID 4688 it was 10 hits, and for Azure Sign-in logs it was 100 hits. Even when logs were intentionally increased to test the tool, the processing completed in about 10 seconds. It is believed that the search time did not simply increase tenfold compared to the results in section 5.4 due to overheads such as loading libraries.

Thus, depending on the scale, the attack can be detected in a maximum of 20 minutes and a few seconds. This method takes about 20 minutes to detect an attack. In targeted attacks, perpetrators tend to infiltrate for long periods, with some remaining undetected for over a year [34]. Although it depends on the attacker's ultimate goal, if misuse of PsExec or breaches into Azure are mid-attack stages, being able to detect an attack within 20 minutes could significantly obstruct the attacker's final objectives.

6.2　Scalability of Performance on Domain Controllers

In this research, we evaluated with 17 accounts. Considering that it would be implemented in real-world scenarios with significantly larger account numbers, we deliberately increased the number of accesses and conducted load testing. The implementation of this proposed method results in the greatest increase in load due to requests for Service Tickets to the Domain Controller. The number of TGT requests, the number of accesses to Azure services do not change with the implementation of this method. Therefore, we intentionally generated a large number of Service Ticket requests to measure the impact on the performance of the Domain Controller. The results are shown in Fig. 7. The x-axis represents the number of requests per minute, which we increased by approximately 100 req/min; specifically, at 98 req/min, 225 req/min, 313 req/min, 424 req/min, and 533 req/min. The y-axis shows CPU and memory usage. It is observed that resource consumption increases with the number of requests, although the increase is minimal. To investigate if this trend remains the same under constant high load conditions, the CPU was kept at constant loads of 50% and 80% using CPUSTRES.exe [35]. For memory, constant loads of 2048MB and 4096MB were maintained using Testlimit.exe [36]. In all scenarios―high CPU load, high memory load, and high loads on both CPU and memory―the trend of load increase due to the rising number of Service Ticket requests was consistent. Furthermore, there were no log loss in any case.

6.3　Scalability of Domain Controller Logs

We measured how the log volume changed in the evaluation period (between January 12th and March 31st, 2023). With the application of the proposed method and the change of the Service Ticket validity period to 10 minutes, the number of outputs for Event ID 4769 increased approximately sevenfold and accounted for 16.5% of the total Event Log. Before the application of the proposed method, Event ID 4769 constituted only 2.8% of the total Event Log. Additionally, We intentionally increased the number of accesses to see the log volume changes. The number of log outputs increased proportionally with the number of accesses to the Domain Controller, while the volume of other Event IDs remained unchanged. However, the size of the logs on the disk did not increase in proportion to the number of log outputs due to compression [37]. In the load test, the size of the log on the disk for only Event ID 4769 was 68 KB with 98 req/min outputs. However, when the outputs ranged from 225 to 533 req/min, the log size was consistently 1092 KB. The specifics of this phenomenon have not been disclosed by Microsoft. However it may be due to compression [37]

6.4　Scalability of Performance to Azure

In our verification environment, as previously mentioned, the number of accesses to the Azure Portal and Microsoft 365 Portal was at most 10 per hour, even during periods of highest activity. It is conceivable that organizations that more often use browser-based services such as Microsoft Outlook or Office. Therefore, we intentionally generated requests, resulting in a rate of 47 requests to Microsoft365 (https://login.microsoftonline.com) per minute. However, there were no occurrences of log losses in either the Windows Event ID 4769 or the Azure sign-in log, nor were there any false detections.

6.5　Evaluation for Recent OS and Services

6.5.1　Windows Server 2022 and Window 11

Even with Windows Server 2022 configured as the Domain Controller, it was possible to change the ticket expiration time to 10 minutes. Additionally, Windows 11 clients request a ticket each time they access Azure services, proving that this method is effective when the Domain Controller is Windows Server 2022 and even when clients operate on Windows 11.

6.5.2　Azure Active Directory Domain Services

Recently, a managed service known as Azure Active Directory Domain Services has become available, which implements some Domain Controller functionalities in the Azure environment, and its usage is expected to increase. Azure Active Directory Domain Services allows for domain joining and Group Policy management directly within the Azure environment. In this study, We install Active Directory administrative tools to manage the domain (this server is referred to as the Azure AD Domain Services Server). However, according to [38], “Azure AD Domain Services is not intended to completely replace existing on-premises Active Directory Domain Controllers. It facilitates the migration of on-premises servers that use traditional protocols such as Kerberos, NTLM, and LDAP to the cloud (Azure), and is meant to reduce the server management burden on organizations (Translated from Japanese by authors.)” Even if Azure Active Directory Domain Services is implemented, it is not recommended to replace on-premises Domain Controllers entirely with Azure AD Domain Services Servers in Azure [38]. Therefore, the on-premises Domain Controller continues to exist within the organization's network, and clients are authenticated through it, making the proposed method effective. Additionally, if the on-premises Domain Controller is compromised, it can lead to the creation of Silver Tickets, potentially compromising Azure Services as well, thus making Attack Scenario 1 valid. Although not recommended, if the on-premises Domain Controller were to be discontinued, attackers would need to steal the AZUREADSSOACC computer account from the Azure AD Domain Services Server to compromise. However, even if user accounts are synchronized from the on-premises Domain Controller, there is no AZUREADSSOACC computer account on the Azure AD Domain Services Server. thereby Attackers can not continue with the attack scenario. However, as previously mentioned, discontinuing the on-premises Domain Controller is not recommended.

7.　Conclusion

Once the on-premise AD environment is compromised, attackers abuse the Silver Ticket to spread the compromise not only to their on-premise environment but also to the Azure services. In this research, we propose a detection method, especially for attacking against the Azure environment, despite detecting the Silver Ticket is difficult. Our proposed methods are easy to implement and perform a high accuracy rate for detection without paid services, especially for the Azure services. This method allows for the identification of computers accessing Azure services without authenticating to the on-premises AD. Furthermore, our methods can also detect the Silver Ticket attack against an on-premise Domain Controller.