learn.microsoft.com Open in urlscan Pro
96.16.156.108  Public Scan

Form analysis
0 forms found in the DOM

Text Content

Skip to main content


This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security
updates, and technical support.

Download Microsoft Edge More info about Internet Explorer and Microsoft Edge

Table of contents Exit focus mode

Read in English Save
Table of contents Read in English Save Feedback Edit Print

Twitter LinkedIn Facebook Email
Table of contents


DOMAIN DOMINANCE ALERTS

 * Article
 * 07/17/2022
 * 32 minutes to read
 * 5 contributors

Feedback


IN THIS ARTICLE

Typically, cyberattacks are launched against any accessible entity, such as a
low-privileged user, and then quickly move laterally until the attacker gains
access to valuable assets. Valuable assets can be sensitive accounts, domain
administrators, or highly sensitive data. Microsoft Defender for Identity
identifies these advanced threats at the source throughout the entire attack
kill chain and classifies them into the following phases:

 1. Reconnaissance
 2. Compromised credentials
 3. Lateral Movements
 4. Domain dominance
 5. Exfiltration

To learn more about how to understand the structure, and common components of
all Defender for Identity security alerts, see Understanding security alerts.
For information about True positive (TP), Benign true positive (B-TP), and False
positive (FP), see security alert classifications.

The following security alerts help you identify and remediate Domain dominance
phase suspicious activities detected by Defender for Identity in your network.
In this article, you'll learn how to understand, classify, prevent, and
remediate the following attacks:

 * Malicious request of Data Protection API master key (external ID 2020)
 * Remote code execution attempt (external ID 2019)
 * Suspected DCShadow attack (domain controller promotion) (external ID 2028)
 * Suspected DCShadow attack (domain controller replication request) (external
   ID 2029)
 * Suspected DCSync attack (replication of directory services) (external ID
   2006)
 * Suspected Golden Ticket usage (encryption downgrade) (external ID 2009)
 * Suspected Golden Ticket usage (forged authorization data) (external ID 2013)
 * Suspected Golden Ticket usage (nonexistent account) (external ID 2027)
 * Suspected Golden Ticket usage (ticket anomaly) (external ID 2032)
 * Suspected Golden Ticket usage (ticket anomaly using RBCD) (external ID 2040)
 * Suspected Golden Ticket usage (time anomaly) (external ID 2022)
 * Suspected Skeleton Key attack (encryption downgrade) (external ID 2010)
 * Suspicious additions to sensitive groups (external ID 2024)
 * Suspicious service creation (external ID 2026)


MALICIOUS REQUEST OF DATA PROTECTION API MASTER KEY (EXTERNAL ID 2020)

Previous name: Malicious Data Protection Private Information Request

Description

The Data Protection API (DPAPI) is used by Windows to securely protect passwords
saved by browsers, encrypted files, and other sensitive data. Domain controllers
hold a backup master key that can be used to decrypt all secrets encrypted with
DPAPI on domain-joined Windows machines. Attackers can use the master key to
decrypt any secrets protected by DPAPI on all domain-joined machines. In this
detection, a Defender for Identity alert is triggered when the DPAPI is used to
retrieve the backup master key.

MITRE

Primary MITRE tactic Credential Access (TA0006) MITRE attack technique
Credentials from Password Stores (T1555) MITRE attack sub-technique N/A

Learning period

None

TP, B-TP, or FP?

Advanced security scanners may legitimately generate this type of activity
against Active Directory.

 1. Check if the source computer is running an organization-approved advanced
    security scanner against Active Directory?
    
    * If the answer is yes, and it shouldn't be running, fix the application
      configuration. This alert is a B-TP and can be Closed.
    * If the answer is yes, and it should always do this, Close the alert, and
      exclude that computer, it's probably a B-TP activity.

Understand the scope of the breach

 1. Investigate the source computer.
 2. If a source user exists, investigate.

Suggested remediation and steps for prevention

 1. Reset the password of the source user and enable MFA or, if you have
    configured the relevant high-risk user policies in Azure Active Directory
    Identity Protection, you can confirm the user is compromised in the
    Microsoft 365 Defender user page.
 2. Contain the source computer.
    * Find the tool that performed the attack and remove it.
    * Look for users who were logged on around the same time as the activity
      occurred, as these users may also be compromised. Reset their passwords
      and enable MFA or, if you have configured the relevant high-risk user
      policies in Azure Active Directory Identity Protection, you can confirm
      the user is compromised in the Microsoft 365 Defender user page.
 3. The stolen private key is never changed. Meaning the actor can always use
    the stolen key to decrypt protected data in the target domain. A
    methodological way to change this private key does not exist.
    * To create a key, use the current private key, create a key, and re-encrypt
      every domain master key with the new private key.


REMOTE CODE EXECUTION ATTEMPT (EXTERNAL ID 2019)

Previous name: Remote code execution attempt

Description

Attackers who compromise administrative credentials or use a zero-day exploit
can execute remote commands on your domain controller or AD FS server. This can
be used for gaining persistency, collecting information, denial of service (DOS)
attacks or any other reason. Defender for Identity detects PSexec, Remote WMI,
and PowerShell connections.

MITRE

Primary MITRE tactic Execution (TA0002) Secondary MITRE tactic Lateral Movement
(TA0008) MITRE attack technique Command and Scripting Interpreter (T1059),Remote
Services (T1021) MITRE attack sub-technique PowerShell (T1059.001), Windows
Remote Management (T1021.006)

Learning period

None

TP, B-TP, or FP

Administrative workstations, IT team members, and service accounts can all
perform legitimate administrative tasks against domain controllers.

 1. Check if the source computer or user is supposed to run those types of
    commands on your domain controller?
    * If the source computer or user is supposed to run those types of commands,
      Close the security alert as a B-TP activity.
    * If the source computer or user is supposed to run those commands on your
      domain controller, and will continue to do so, it is a B-TP activity.
      Close the security alert and exclude the computer.

Understand the scope of the breach

 1. Investigate the source computer and user.
 2. Investigate the domain controller.

Suggested remediation and steps for prevention:

Remediation

 1. Reset the password of the source users and enable MFA or, if you have
    configured the relevant high-risk user policies in Azure Active Directory
    Identity Protection, you can confirm the user is compromised in the
    Microsoft 365 Defender user page.
 2. Contain the domain controllers by:
    * Remediate the remote code execution attempt.
    * Look for users logged on around the same time as the suspicious activity,
      as they may also be compromised. Reset their passwords and enable MFA or,
      if you have configured the relevant high-risk user policies in Azure
      Active Directory Identity Protection, you can confirm the user is
      compromised in the Microsoft 365 Defender user page.
 3. Contain the source computer.
    * Find the tool that performed the attack and remove it.
    * Look for users logged on around the same time as the suspicious activity,
      as they may also be compromised. Reset their passwords and enable MFA or,
      if you have configured the relevant high-risk user policies in Azure
      Active Directory Identity Protection, you can confirm the user is
      compromised in the Microsoft 365 Defender user page.

Prevention

 1. Restrict remote access to domain controllers from non-Tier 0 machines.
 2. Implement privileged access. allowing only hardened machines to connect to
    domain controllers for admins.
 3. Implement less-privileged access on domain machines to allow specific users
    the right to create services.

Note

Remote code execution attempt alerts on attempted use of Powershell commands are
only supported by Defender for Identity sensors.


SUSPECTED DCSHADOW ATTACK (DOMAIN CONTROLLER PROMOTION) (EXTERNAL ID 2028)

Previous name: Suspicious domain controller promotion (potential DCShadow
attack)

Description

A domain controller shadow (DCShadow) attack is an attack designed to change
directory objects using malicious replication. This attack can be performed from
any machine by creating a rogue domain controller using a replication process.

In a DCShadow attack, RPC, and LDAP are used to:

 1. Register the machine account as a domain controller (using domain admin
    rights).
 2. Perform replication (using the granted replication rights) over DRSUAPI and
    send changes to directory objects.

In this Defender for Identity detection, a security alert is triggered when a
machine in the network tries to register as a rogue domain controller.

MITRE

Primary MITRE tactic Defense Evasion (TA0005) MITRE attack technique Rogue
Domain Controller (T1207) MITRE attack sub-technique N/A

Learning period

None

TP, B-TP, or FP

If the source computer is a domain controller, failed or low certainty
resolution can prevent Defender for Identity from being able to confirm
identification.

 1. Check if the source computer is a domain controller? If the answer is yes,
    Close the alert as a B-TP activity.

Changes in your Active Directory can take time to synchronize.

 1. Is the source computer a newly promoted domain controller? If the answer is
    yes, Close the alert as a B-TP activity.

Servers and applications might replicate data from Active Directory, such as
Azure AD Connect or network performance monitoring devices.

 1. Check if this source computer is supposed to generate this type of activity?
    
    * If the answer is yes, but the source computer should not continue
      generating this type of activity in the future, fix the configuration of
      the server/application. Close the security alert as a B-TP activity.
    
    * If the answer is yes and the source computer should continue generating
      this type of activity in the future, Close the security alert as a B-TP
      activity, and exclude the computer to avoid additional benign alerts.

Understand the scope of the breach

 1. Investigate the source computer.
 2. Look at the Event Viewer to see Active Directory events that it records in
    the directory services log. You can use the log to monitor changes in Active
    Directory. By default, Active Directory only records critical error events,
    but if this alert recurs, enable this audit on the relevant domain
    controller for further investigation.

Suggested remediation and steps for prevention:

Remediation:

 1. Contain the source computer.
    * Find the tool that performed the attack and remove it.
    * Look for users who were logged on around the same time as the activity
      occurred, as these users may also be compromised. Reset their passwords
      and enable MFA or, if you have configured the relevant high-risk user
      policies in Azure Active Directory Identity Protection, you can confirm
      the user is compromised in the Microsoft 365 Defender user page.

Prevention:

Validate the following permissions:

 1. Replicate directory changes.
 2. Replicate directory changes all.
 3. For more information, see Grant Active Directory Domain Services permissions
    for profile synchronization in SharePoint Server 2013. You can use AD ACL
    Scanner or create a Windows PowerShell script to determine who has these
    permissions in the domain.

Note

Suspicious domain controller promotion (potential DCShadow attack) alerts are
supported by Defender for Identity sensors only.


SUSPECTED DCSHADOW ATTACK (DOMAIN CONTROLLER REPLICATION REQUEST) (EXTERNAL ID
2029)

Previous name: Suspicious replication request (potential DCShadow attack)

Description

Active Directory replication is the process by which changes that are made on
one domain controller are synchronized with other domain controllers. Given
necessary permissions, attackers can grant rights for their machine account,
allowing them to impersonate a domain controller. Attackers strive to initiate a
malicious replication request, allowing them to change Active Directory objects
on a genuine domain controller, which can give the attackers persistence in the
domain. In this detection, an alert is triggered when a suspicious replication
request is generated against a genuine domain controller protected by Defender
for Identity. The behavior is indicative of techniques used in domain controller
shadow attacks.

MITRE

Primary MITRE tactic Defense Evasion (TA0005) MITRE attack technique Rogue
Domain Controller (T1207) MITRE attack sub-technique N/A

Learning period

None

TP, B-TP, or FP

If the source computer is a domain controller, failed or low certainty
resolution can prevent Defender for Identity from identification.

 1. Check if the source computer is a domain controller? If the answer is yes,
    Close the alert as a B-TP activity.

Changes in your Active Directory can take time to synchronize.

 1. Is the source computer a newly promoted domain controller? If the answer is
    yes, Close the alert as a B-TP activity.

Servers and applications might replicate data from Active Directory, such as
Azure AD Connect or network performance monitoring devices.

 1. Was this source computer supposed to generate this type of activity?
    
    * If the answer is yes, but the source computer should not continue
      generating this type of activity in the future, fix the configuration of
      the server/application. Close the security alert as a B-TP activity.
    
    * If the answer is yes, and the source computer should continue generating
      this type of activity in the future, Close the security alert as a B-TP
      activity, and exclude the computer to avoid additional B-TP alerts.

Understand the scope of the breach

 1. Investigate the source computer.

Suggested remediation and steps for prevention

Remediation:

 1. Contain the source computer.
    * Find the tool that performed the attack and remove it.
    * Look for users who were logged on around the same time as the activity
      occurred, as these users may also be compromised. Reset their passwords
      and enable MFA or, if you have configured the relevant high-risk user
      policies in Azure Active Directory Identity Protection, you can confirm
      the user is compromised in the Microsoft 365 Defender user page.
 2. Remediate the data that was replicated on the domain controllers.

Prevention:

Validate the following permissions:

 1. Replicate directory changes.
 2. Replicate directory changes all.
 3. For more information, see Grant Active Directory Domain Services permissions
    for profile synchronization in SharePoint Server 2013. You can use AD ACL
    Scanner or create a Windows PowerShell script to determine who in the domain
    has these permissions.

Note

Suspicious replication request (potential DCShadow attack) alerts are supported
by Defender for Identity sensors only.


SUSPECTED DCSYNC ATTACK (REPLICATION OF DIRECTORY SERVICES) (EXTERNAL ID 2006)

Previous name: Malicious replication of directory services

Description

Active Directory replication is the process by which changes that are made on
one domain controller are synchronized with all other domain controllers. Given
necessary permissions, attackers can initiate a replication request, allowing
them to retrieve the data stored in Active Directory, including password hashes.

In this detection, an alert is triggered when a replication request is initiated
from a computer that isn't a domain controller.

Note

If you have domain controllers on which Defender for Identity sensors are not
installed, those domain controllers are not covered by Defender for Identity.
When deploying a new domain controller on an unregistered or unprotected domain
controller, it may not immediately be identified by Defender for Identity as a
domain controller. It is highly recommended to install the Defender for Identity
sensor on every domain controller to get full coverage.

MITRE

Primary MITRE tactic Credential Access (TA0006) Secondary MITRE tactic
Persistence (TA0003) MITRE attack technique OS Credential Dumping (T1003) MITRE
attack sub-technique DCSync (T1003.006)

Learning period

None

TP, B-TP, or FP

If the source computer is a domain controller, failed or low certainty
resolution can prevent Defender for Identity from identification.

 1. Check if the source computer is a domain controller? If the answer is yes,
    Close the alert as a B-TP activity.

Changes in your Active Directory can take time to synchronize.

 1. Is the source computer a newly promoted domain controller? If the answer is
    yes, Close the alert as a B-TP activity.

Servers and applications might replicate data from Active Directory, such as
Azure AD Connect or network performance monitoring devices.

 1. Was this source computer was supposed to generate this type of activity?
    
    * If the answer is yes, but the source computer should not continue to
      generate this type of activity in the future, fix the configuration of the
      server/application. Close the security alert as a B-TP activity.
    
    * If the answer is yes, and the source computer should continue to generate
      this type of activity in the future, Close the security alert as a B-TP
      activity, and exclude the computer to avoid additional benign alerts.

Understand the scope of the breach

 1. Investigate the source computer and user.

Suggested remediation and steps for prevention:

Remediation:

 1. Reset the password of the source users and enable MFA or, if you have
    configured the relevant high-risk user policies in Azure Active Directory
    Identity Protection, you can confirm the user is compromised in the
    Microsoft 365 Defender user page.
 2. Contain the source computer.
    * Find the tool that performed the attack and remove it.
    * Look for users who were logged on around the same time as the activity
      occurred, as these users may also be compromised. Reset their passwords
      and enable MFA or, if you have configured the relevant high-risk user
      policies in Azure Active Directory Identity Protection, you can confirm
      the user is compromised in the Microsoft 365 Defender user page.

Prevention:

Validate the following permissions:

 1. Replicate directory changes.
 2. Replicate directory changes all.
 3. For more information, see Grant Active Directory Domain Services permissions
    for profile synchronization in SharePoint Server 2013. You can use AD ACL
    Scanner or create a Windows PowerShell script to determine who in the domain
    has these permissions.


SUSPECTED GOLDEN TICKET USAGE (ENCRYPTION DOWNGRADE) (EXTERNAL ID 2009)

Previous name: Encryption downgrade activity

Description

Encryption downgrade is a method of weakening Kerberos by downgrading the
encryption level of different protocol fields that normally have the highest
level of encryption. A weakened encrypted field can be an easier target to
offline brute force attempts. Various attack methods utilize weak Kerberos
encryption cyphers. In this detection, Defender for Identity learns the Kerberos
encryption types used by computers and users, and alerts you when a weaker
cypher is used that is unusual for the source computer and/or user and matches
known attack techniques.

In a Golden Ticket alert, the encryption method of the TGT field of TGS_REQ
(service request) message from the source computer was detected as downgraded
compared to the previously learned behavior. This is not based on a time anomaly
(as in the other Golden Ticket detection). In addition, in the case of this
alert, there was no Kerberos authentication request associated with the previous
service request, detected by Defender for Identity.

MITRE

Primary MITRE tactic Persistence (TA0003) Secondary MITRE tactic Privilege
Escalation (TA0004), Lateral Movement (TA0008) MITRE attack technique Steal or
Forge Kerberos Tickets (T1558) MITRE attack sub-technique Golden
Ticket(T1558.001)

Learning period

This alert has a learning period of 5 days from the start of domain controller
monitoring.

TP, B-TP, or FP

Some legitimate resources don't support strong encryption ciphers and may
trigger this alert.

 1. Do all of the source users share something in common?
    
    1. For example, are all of your marketing personnel accessing a specific
       resource that could cause the alert to be triggered?
    
    2. Check the resources accessed by those tickets.
       
       * Check this in Active Directory by checking the attribute
         msDS-SupportedEncryptionTypes, of the resource service account.
    
    3. If there is only one resource being accessed, check if is a valid
       resource these users are supposed to access.
       
       If the answer to one of the previous questions is yes, it is likely to be
       a B-TP activity. Check if the resource can support a strong encryption
       cipher, implement a stronger encryption cipher where possible, and Close
       the security alert.

Applications might authenticate using a lower encryption cipher. Some are
authenticating on behalf of users, such as IIS and SQL servers.

 1. Check if the source users have something in common.
    
    * For example, do all of your sales personnel use a specific app that might
      trigger the alert?
    * Check if there are applications of this type on the source computer.
    * Check the computer roles. Are they servers that work with these types of
      applications?
    
    If the answer to one of the previous questions is yes, it is likely to be a
    B-TP activity. Check if the resource can support a strong encryption
    cipher,implement a stronger encryption cipher where possible, and Close the
    security alert.

Understand the scope of the breach

 1. Investigate the source computer and resources that were accessed.
 2. Investigate the users.

Suggested remediation and steps for prevention

Remediation

 1. Reset the password of the source user and enable MFA or, if you have
    configured the relevant high-risk user policies in Azure Active Directory
    Identity Protection, you can confirm the user is compromised in the
    Microsoft 365 Defender user page.

 2. Contain the source computer.
    
    * Find the tool that performed the attack and remove it.
    * Look for users logged on around the time of the activity, as they may also
      be compromised. Reset their passwords and enable MFA or, if you have
      configured the relevant high-risk user policies in Azure Active Directory
      Identity Protection, you can confirm the user is compromised in the
      Microsoft 365 Defender user page.
    * If you have Microsoft Defender for Endpoint installed – use klist.exe
      purge to delete all the tickets of the specified logon session and prevent
      future usage of the tickets.

 3. Contain the resources that were accessed by this ticket.

 4. Change the Kerberos Ticket Granting Ticket (KRBTGT) password twice according
    to the guidance in the KRBTGT account article.
    
    * Resetting the KRBTGT twice invalidates all Kerberos tickets in this
      domain. Invalidating all Kerberos tickets in the domain means all services
      will be broken and they will not work again until they are renewed or in
      some cases, the service is restarted.
    * Plan carefully before performing the KRBTGT double reset. The KRBTGT
      double reset impacts all computers, servers, and users in the environment.

 5. Make sure all domain controllers with operating systems up to Windows Server
    2012 R2 are installed with KB3011780 and all member servers and domain
    controllers up to 2012 R2 are up-to-date with KB2496930. For more
    information, see Silver PAC and Forged PAC.


SUSPECTED GOLDEN TICKET USAGE (FORGED AUTHORIZATION DATA) (EXTERNAL ID 2013)

Previous name: Privilege escalation using forged authorization data

Description

Known vulnerabilities in older versions of Windows Server allow attackers to
manipulate the Privileged Attribute Certificate (PAC), a field in the Kerberos
ticket that contains a user authorization data (in Active Directory this is
group membership), granting attackers additional privileges.

MITRE

Primary MITRE tactic Credential Access (TA0006) MITRE attack technique Steal or
Forge Kerberos Tickets (T1558) MITRE attack sub-technique Golden Ticket
(T1558.001)

Learning period

None

TP, B-TP, or FP

For computers that are patched with MS14-068 (domain controller) or MS11-013
(server) attempted attacks will not succeed, and will generate Kerberos error.

 1. Check which resources were accessed in the security alert evidence list, and
    if the attempts were successful or failed.
 2. Check if the accessed computers were patched, as described above?
    * If the computers were patched, Close the security alert as a B-TP
      activity.

Some Operating Systems or applications are known to modify the authorization
data. For example, Linux and Unix services have their own authorization
mechanism which may trigger the alert.

 1. Is the source computer running an OS or application that has its own
    authorization mechanism?
    * If the source computer is running this type of authorization mechanism,
      consider upgrading the OS or fixing the application configuration. Close
      the alert as a B-TP activity.

Understand the scope of the breach

 1. Investigate the source computer.
 2. If there is a source user, investigate.
 3. Check which resources were accessed successfully and investigate.

Suggested remediation and steps for prevention

 1. Reset the password of the source user and enable MFA or, if you have
    configured the relevant high-risk user policies in Azure Active Directory
    Identity Protection, you can confirm the user is compromised in the
    Microsoft 365 Defender user page.
 2. Contain the source computer
    * Find the tool that preformed the attack and remove it.
    * Look for users logged on around the same time as the activity, as they may
      also be compromised. Reset their passwords and enable MFA or, if you have
      configured the relevant high-risk user policies in Azure Active Directory
      Identity Protection, you can confirm the user is compromised in the
      Microsoft 365 Defender user page.
 3. Change the Kerberos Ticket Granting Ticket (KRBTGT) password twice according
    to the guidance in the KRBTGT account article.
    * Resetting the KRBTGT twice invalidates all Kerberos tickets in this
      domain. Invalidating all Kerberos tickets in the domain means all services
      will be broken and they will not work again until they are renewed or in
      some cases, the service is restarted. Plan carefully before performing the
      KRBTGT double reset, because it impacts all computers, servers and users
      in the environment.
 4. Make sure all domain controllers with operating systems up to Windows Server
    2012 R2 are installed with KB3011780 and all member servers and domain
    controllers up to 2012 R2 are up-to-date with KB2496930. For more
    information, see Silver PAC and Forged PAC.


SUSPECTED GOLDEN TICKET USAGE (NONEXISTENT ACCOUNT) (EXTERNAL ID 2027)

Previous name: Kerberos golden ticket

Description

Attackers with domain admin rights can compromise the KRBTGT account. Using the
KRBTGT account, they can create a Kerberos ticket granting ticket (TGT) that
provides authorization to any resource and set the ticket expiration to any
arbitrary time. This fake TGT is called a "Golden Ticket" and allows attackers
to achieve network persistence. In this detection, an alert is triggered by a
nonexistent account.

Primary MITRE tactic Persistence (TA0003) Secondary MITRE tactic Privilege
Escalation (TA0004), Lateral Movement (TA0008) MITRE attack technique Steal or
Forge Kerberos Tickets (T1558), Exploitation for Privilege Escalation (T1068),
Exploitation of Remote Services (T1210) MITRE attack sub-technique Golden
Ticket(T1558.001)

Learning period

None

TP, B-TP, or FP

Changes in Active Directory can take time to synchronize.

 1. Is the user a known and valid domain user?
 2. Has the user been recently added?
 3. Was the user been recently deleted from Active Directory?

If the answer is yes to all of the previous questions, Close the alert, as a
B-TP activity.

Understand the scope of the breach

 1. Investigate the source computer and accessed resources.

Suggested remediation and steps for prevention

 1. Contain the source computers
    * Find the tool that performed the attack and remove it.
    * Look for users logged on around the same time as the activity, as they may
      also be compromised. Reset their passwords and enable MFA or, if you have
      configured the relevant high-risk user policies in Azure Active Directory
      Identity Protection, you can confirm the user is compromised in the
      Microsoft 365 Defender user page.
    * If you have Microsoft Defender for Endpoint installed – use klist.exe
      purge to delete all the tickets of the specified logon session and prevent
      future usage of the tickets.
 2. Contain the resources that were accessed by this ticket.
 3. Change the Kerberos Ticket Granting Ticket (KRBTGT) password twice according
    to the guidance in the KRBTGT account article.
    * Resetting the KRBTGT twice invalidates all Kerberos tickets in this
      domain. Invalidating all Kerberos tickets in the domain means all services
      will be broken and they will not work again until they are renewed or in
      some cases, the service is restarted. Plan carefully before performing the
      KRBTGT double reset, because it impacts all computers, servers and users
      in the environment.


SUSPECTED GOLDEN TICKET USAGE (TICKET ANOMALY) (EXTERNAL ID 2032)

Description

Attackers with domain admin rights can compromise the KRBTGT account. Using the
KRBTGT account, they can create a Kerberos ticket granting ticket (TGT) that
provides authorization to any resource and set the ticket expiration to any
arbitrary time. This fake TGT is called a "Golden Ticket" and allows attackers
to achieve network persistence. Forged Golden Tickets of this type have unique
characteristics this detection is specifically designed to identify.

MITRE

Primary MITRE tactic Persistence (TA0003) Secondary MITRE tactic Privilege
Escalation (TA0004), Lateral Movement (TA0008) MITRE attack technique Steal or
Forge Kerberos Tickets (T1558) MITRE attack sub-technique Golden
Ticket(T1558.001)

Learning period

None

TP, B-TP, or FP

Federation services might generate tickets that will trigger this alert.

 1. Does the source computer host Federation services that generate these types
    of tickets?
    * If the source computer hosts services that generate these types of
      tickets, Close the security alert as a B-TP activity.

Understand the scope of the breach

 1. Investigate the source computer and accessed resources.
 2. Investigate the source user.

Suggested remediation and steps for prevention

 1. Contain the source computers
    
    * Find the tool that performed the attack and remove it.
    * Look for users logged on around the same time as the activity, as they may
      also be compromised. Reset their passwords and enable MFA or, if you have
      configured the relevant high-risk user policies in Azure Active Directory
      Identity Protection, you can confirm the user is compromised in the
      Microsoft 365 Defender user page.
    * If you have Microsoft Defender for Endpoint installed – use klist.exe
      purge to delete all the tickets of the specified logon session and prevent
      future usage of the tickets.

 2. Contain the resources that were accessed by this ticket.

 3. Change the Kerberos Ticket Granting Ticket (KRBTGT) password twice according
    to the guidancein the KRBTGT account article.
    
    * Resetting the KRBTGT twice invalidates all Kerberos tickets in this
      domain. Invalidating all Kerberos tickets in the domain means all services
      are broken and cannot work again until renewed or in some cases, the
      service is restarted.
    
    Plan carefully before performing a KRBTGT double reset. The reset impacts
    all computers, servers, and users in the environment.


SUSPECTED GOLDEN TICKET USAGE (TICKET ANOMALY USING RBCD) (EXTERNAL ID 2040)

Description

Attackers with domain admin rights can compromise the KRBTGT account. Using the
KRBTGT account, they can create a Kerberos ticket granting ticket (TGT) that
provides authorization to any resource. This fake TGT is called a "Golden
Ticket" and allows attackers to achieve network persistence. In this detection,
the alert is triggered by a golden ticket that was created by setting Resource
Based Constrained Delegation (RBCD) permissions using the KRBTGT account for
account (user\computer) with SPN.

MITRE

Primary MITRE tactic Persistence (TA0003) Secondary MITRE tactic Privilege
Escalation (TA0004) MITRE attack technique Steal or Forge Kerberos Tickets
(T1558) MITRE attack sub-technique Golden Ticket(T1558.001)

Learning period

None

TP, B-TP, or FP

 1. Federation services might generate tickets that will trigger this alert.
    Does the source computer host such services?
    * If yes, Close the security alert as a B-TP
 2. View the source user's profile page and check what happened around the time
    of the activity.
    1. Is the user supposed to have access to this resource?
    2. Is the principal expected to access that service?
    3. Are all the users who were logged into the computer supposed to be logged
       into it?
    4. Are the privileges appropriate for the account?
 3. Should the users who were logged in have access to these resources?
    * If you enabled Microsoft Defender for Endpoint integration, select on its
      icon to further investigate.

If the answer to any of the previous questions is yes, Close the security alert
as a FP.

Understand the scope of the breach

 1. Investigate the source computer and resources that were accessed.
 2. Investigate the users.

Suggested remediation and steps for prevention:

 1. Follow the instructions in the unsecure Kerberos delegation security
    assessment.
 2. Review the sensitive users listed in the alert and remove them from the
    resource.
 3. Change the Kerberos Ticket Granting Ticket (KRBTGT) password twice according
    to the guidance in the KRBTGT account article. Resetting the KRBTGT twice
    invalidates all Kerberos tickets in this domain so plan before doing so.
    Also, because creating a Golden Ticket requires domain admin rights,
    implement Pass the hash recommendations.


SUSPECTED GOLDEN TICKET USAGE (TIME ANOMALY) (EXTERNAL ID 2022)

Previous name: Kerberos golden ticket

Description

Attackers with domain admin rights can compromise the KRBTGT account. Using the
KRBTGT account, they can create a Kerberos ticket granting ticket (TGT) that
provides authorization to any resource and set the ticket expiration to any
arbitrary time. This fake TGT is called a "Golden Ticket" and allows attackers
to achieve network persistence. This alert is triggered when a Kerberos ticket
granting ticket is used for more than the allowed time permitted, as specified
in the Maximum lifetime for user ticket.

MITRE

Primary MITRE tactic Persistence (TA0003) Secondary MITRE tactic Privilege
Escalation (TA0004), Lateral Movement (TA0008) MITRE attack technique Steal or
Forge Kerberos Tickets (T1558) MITRE attack sub-technique Golden
Ticket(T1558.001)

Learning period

None

TP, B-TP, or FP

 1. In the last few hours, was there any change made to the Maximum lifetime for
    user ticket setting in group policy, that might affect the alert?
 2. Is the Defender for Identity Standalone Sensor involved in this alert a
    virtual machine?
    * If the Defender for Identity standalone sensor is involved, was it
      recently resumed from a saved state?
 3. Is there a time synchronization problem in the network, where not all of the
    computers are synchronized?
    * Select the Download details button to view the Security Alert report Excel
      file, view the related network activities, and check if there's a
      difference between "StartTime" and "DomainControllerStartTime".

If the answer to the previous questions is yes, Close the security alert as a
B-TP activity.

Understand the scope of the breach

 1. Investigate the source computer and accessed resources.
 2. Investigate the compromised user.

Suggested remediation and steps for prevention

 1. Contain the source computer.
    
    * Find the tool that performed the attack and remove it.
    * Look for users logged on around the same time as the activity, as they may
      also be compromised. Reset their passwords and enable MFA or, if you have
      configured the relevant high-risk user policies in Azure Active Directory
      Identity Protection, you can confirm the user is compromised in the
      Microsoft 365 Defender user page.
    * If you have Microsoft Defender for Endpoint installed – use klist.exe
      purge to delete all the tickets of the specified logon session and prevent
      future usage of the tickets.

 2. Contain the resources accessed by this ticket.

 3. Change the Kerberos Ticket Granting Ticket (KRBTGT) password twice according
    to the guidance in the KRBTGT account article.
    
    * Resetting the KRBTGT twice invalidates all Kerberos tickets in this
      domain. Invalidating all Kerberos tickets in the domain means all services
      are broken, and won't work again until they are renewed or in some cases,
      the service is restarted.
    
    Plan carefully before performing a KRBTGT double reset. The reset impacts
    all computers, servers, and users in the environment.


SUSPECTED SKELETON KEY ATTACK (ENCRYPTION DOWNGRADE) (EXTERNAL ID 2010)

Previous name: Encryption downgrade activity

Description

Encryption downgrade is a method of weakening Kerberos using a downgraded
encryption level for different fields of the protocol that normally have the
highest level of encryption. A weakened encrypted field can be an easier target
to offline brute force attempts. Various attack methods utilize weak Kerberos
encryption cyphers. In this detection, Defender for Identity learns the Kerberos
encryption types used by computers and users. The alert is issued when a weaker
cypher is used that is unusual for the source computer, and/or user, and matches
known attack techniques.

Skeleton Key is malware that runs on domain controllers and allows
authentication to the domain with any account without knowing its password. This
malware often uses weaker encryption algorithms to hash the user's passwords on
the domain controller. In this alert, the learned behavior of previous KRB_ERR
message encryption from domain controller to the account requesting a ticket,
was downgraded.

MITRE

Primary MITRE tactic Persistence (TA0003) Secondary MITRE tactic Lateral
Movement (TA0008) MITRE attack technique Exploitation of Remote Services
(T1210),Modify Authentication Process (T1556) MITRE attack sub-technique Domain
Controller Authentication (T1556.001)

Understand the scope of the breach

 1. Investigate the domain controller.
 2. Check if Skeleton Key has affected your domain controllers.
 3. Investigate the users and computers involved.

Suggested remediation and prevention steps

 1. Reset the passwords of the compromised users and enable MFA or, if you have
    configured the relevant high-risk user policies in Azure Active Directory
    Identity Protection, you can confirm the user is compromised in the
    Microsoft 365 Defender user page.
 2. Contain the domain controller.
    * Remove the malware. For more information, see Skeleton Key Malware
      Analysis.
    * Look for users logged on around the same time as the suspicious activity
      occurred, as they may also be compromised. Reset their passwords and
      enable MFA or, if you have configured the relevant high-risk user policies
      in Azure Active Directory Identity Protection, you can confirm the user is
      compromised in the Microsoft 365 Defender user page.


SUSPICIOUS ADDITIONS TO SENSITIVE GROUPS (EXTERNAL ID 2024)

Description

Attackers add users to highly privileged groups. Adding users is done to gain
access to more resources, and gain persistency. This detection relies on
profiling the group modification activities of users, and alerting when an
abnormal addition to a sensitive group is seen. Defender for Identity profiles
continuously.

For a definition of sensitive groups in Defender for Identity, see Working with
the sensitive accounts.

The detection relies on events audited on domain controllers. Make sure your
domain controllers are auditing the events needed.

MITRE

Primary MITRE tactic Persistence (TA0003) Secondary MITRE tactic Credential
Access (TA0006) MITRE attack technique Account Manipulation (T1098),Domain
Policy Modification (T1484) MITRE attack sub-technique N/A

Learning period

Four weeks per domain controller, starting from the first event.

TP, B-TP, or FP

Legitimate group modifications that occur rarely and the system didn't learn as
"normal", may trigger an alert. These alerts would be considered B-TP.

 1. Is the group modification legitimate?
    * If the group modification is legitimate, Close the security alert as a
      B-TP activity.

Understand the scope of the breach

 1. Investigate the users added to groups.
    * Focus on their activities after they were added to the sensitive groups.
 2. Investigate the source user.
    * Download the Sensitive Group Modification report to see what other
      modifications were made an who made them in the same time period.
 3. Investigate the computers the source user was logged into, around the time
    of the activity.

Suggested remediation and steps for prevention

Remediation:

 1. Reset the password of the source user and enable MFA or, if you have
    configured the relevant high-risk user policies in Azure Active Directory
    Identity Protection, you can confirm the user is compromised in the
    Microsoft 365 Defender user page.
    * Look for the computer the source user was active on.
    * Check which computers the user was logged into around the same time as the
      activity. Check if these computers are compromised.
    * If the users are compromised, reset their passwords and enable MFA or, if
      you have configured the relevant high-risk user policies in Azure Active
      Directory Identity Protection, you can confirm the user is compromised in
      the Microsoft 365 Defender user page.

Prevention:

 1. To help prevent future attacks, minimize the number of users authorized to
    modify sensitive groups.
 2. Set up Privileged Access Management for Active Directory if applicable.


SUSPICIOUS SERVICE CREATION (EXTERNAL ID 2026)

Previous name: Suspicious service creation

Description

A suspicious service has been created on a domain controller or AD FS server in
your organization. This alert relies on event 7045 to identify this suspicious
activity.

MITRE

Primary MITRE tactic Execution (TA0002) Secondary MITRE tactic Persistence
(TA0003), Privilege Escalation (TA0004), Defense Evasion (TA0005), Lateral
Movement (TA0008) MITRE attack technique Remote Services (T1021), Command and
Scripting Interpreter (T1059), System Services (T1569), Create or Modify System
Process (T1543) MITRE attack sub-technique Service Execution (T1569.002),
Windows Service (T1543.003)

Learning period

None

TP, B-TP, or FP

Some administrative tasks are legitimately performed against domain controllers
by administrative workstations, IT team members, and service accounts.

 1. Is the source user/computer supposed to run these types of services on the
    domain controller?
    * If the source user or computer is supposed to run these types of services,
      and should not continue to, Close the alert as a B-TP activity.
    * If the source user or computer is supposed to run these types of services,
      and should continue to, Close the security alert as a B-TP activity, and
      exclude that computer.

Understand the scope of the breach

 1. Investigate the source user.
 2. Investigate the destination computers the services were created on.

Suggested remediation and steps for prevention

Remediation

 1. Reset the password of the source user and enable MFA or, if you have
    configured the relevant high-risk user policies in Azure Active Directory
    Identity Protection, you can confirm the user is compromised in the
    Microsoft 365 Defender user page.
 2. Contain the domain controllers.
    * Remediate the suspicious service.
    * Look for users logged on around the time of the activity, as they may also
      be compromised. Reset their passwords and enable MFA or, if you have
      configured the relevant high-risk user policies in Azure Active Directory
      Identity Protection, you can confirm the user is compromised in the
      Microsoft 365 Defender user page.
 3. Locate the computer the source user was active on.
    * Check the computers the user was logged into around the same time as the
      activity, and check if these computers are also compromised.

Prevention:

 1. Restrict remote access to domain controllers from non-Tier 0 machines.
 2. Implement privileged access to allow only hardened machines to connect to
    domain controllers for administrators.
 3. Implement less-privileged access on domain machines to give only specific
    users the right to create services.

Exfiltration alerts


SEE ALSO

 * Investigate a computer
 * Working with security alerts
 * Working with lateral movement paths
 * Reconnaissance alerts
 * Compromised credential alerts
 * Lateral movement alerts
 * Exfiltration alerts
 * Check out the Defender for Identity forum!









FEEDBACK

Submit and view feedback for

This product This page
View all page feedback

Theme
 * Light
 * Dark
 * High contrast

 * 
 * Previous Versions
 * Blog
 * Contribute
 * Privacy
 * Terms of Use
 * Trademarks
 * © Microsoft 2022


IN THIS ARTICLE




Theme
 * Light
 * Dark
 * High contrast

 * 
 * Previous Versions
 * Blog
 * Contribute
 * Privacy
 * Terms of Use
 * Trademarks
 * © Microsoft 2022