Active Directory — CraftedSignal Threat Feed

Potential Active Directory Replication Account Backdoor

hello@craftedsignal.io — Mon, 04 May 2026 14:17:05 +0000

This detection rule identifies modifications to the nTSecurityDescriptor attribute within Active Directory (AD) objects that grant DCSync-related permissions to a user or computer account. This technique allows attackers to create a persistent backdoor, enabling them to re-obtain access to user and computer account hashes. The modification involves assigning specific GUIDs that represent replication rights (1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, 89e95b76-444d-4c62-991a-0facbeda640c) to an account’s security descriptor. This allows the attacker to then use DCSync to retrieve credentials from the domain, effectively bypassing normal authentication mechanisms.

Attack Chain

The attacker gains initial access to an account with sufficient privileges to modify Active Directory objects (e.g., Domain Admin).
The attacker uses AD management tools (PowerShell, ADSI Edit, etc.) to target a specific user or computer account.
The attacker modifies the nTSecurityDescriptor attribute of the targeted account.
The attacker grants replication rights to the targeted account by adding specific Access Control Entries (ACEs) containing the GUIDs 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, and 89e95b76-444d-4c62-991a-0facbeda640c.
The attacker uses the DCSync technique, impersonating a domain controller, to request password hashes.
The Active Directory server, believing the request is legitimate due to the granted replication rights, provides the attacker with the requested credential information.
The attacker obtains password hashes for domain users and computers.
The attacker uses the obtained credentials for lateral movement, privilege escalation, or data exfiltration.

Impact

Successful exploitation allows attackers to compromise the entire Active Directory domain by gaining access to sensitive credential data. This could lead to complete control over the network, including access to critical systems, sensitive data, and the ability to disrupt business operations. The modification of security descriptors creates a persistent backdoor that can be used repeatedly to harvest credentials.

Recommendation

Enable Audit Directory Service Changes to generate the necessary event logs for detection (https://ela.st/audit-directory-service-changes).
Deploy the Sigma rule provided below to detect unauthorized modifications to the nTSecurityDescriptor attribute. Tune the rule to exclude legitimate administrative accounts or scripts that may perform authorized modifications.
Monitor Windows Security Event Logs (event code 5136) for changes to the nTSecurityDescriptor attribute and investigate any unexpected modifications, focusing on the presence of DCSync-related GUIDs.
Regularly review and audit Active Directory permissions, focusing on accounts with replication rights, to ensure they are legitimate and necessary.

Active Directory Group Modification by SYSTEM Account

hello@craftedsignal.io — Sat, 02 Nov 2024 23:59:00 +0000

This detection identifies a user being added to an Active Directory (AD) group by the SYSTEM account (S-1-5-18). This behavior is significant because it can indicate an attacker who has successfully achieved SYSTEM level privileges on a domain controller. Attackers typically obtain SYSTEM privileges by exploiting vulnerabilities in the domain controller, or by abusing default group privileges such as those assigned to Server Operators. Once SYSTEM access is achieved, the attacker can then attempt to pivot to a domain account. This allows them to gain persistent access and control over the AD environment. Successful exploitation enables attackers to perform actions with the privileges of the compromised account, leading to potential data breaches, system compromise, and further lateral movement within the network.

Attack Chain

Initial Access: An attacker gains initial access to the network through various means, such as phishing or exploiting a public-facing application.
Privilege Escalation: The attacker exploits a vulnerability or misconfiguration on a system within the network to achieve local administrator or SYSTEM privileges.
Domain Controller Compromise: The attacker uses their elevated privileges to target a domain controller, exploiting vulnerabilities or weak configurations to gain SYSTEM access on the domain controller itself.
Group Modification: Once the attacker has SYSTEM privileges on a domain controller, they use this access to add a user account to a privileged Active Directory group. This is done by modifying the group membership using tools native to the operating system.
Persistence: By adding a user account to a privileged group, the attacker ensures they have persistent access to the domain, even if their initial access method is discovered and blocked.
Lateral Movement: With the newly acquired group membership, the attacker can now move laterally within the network, accessing resources and systems that were previously inaccessible.
Data Exfiltration / Impact: The attacker leverages their access to locate and exfiltrate sensitive data, or to disrupt critical business operations.

Impact

A successful attack can lead to a wide range of negative consequences, including data breaches, system compromise, and disruption of critical business operations. Attackers can use the compromised account to access sensitive data, modify system configurations, or even deploy ransomware. The scope of impact depends on the permissions and privileges associated with the compromised account and the targeted resources. Furthermore, the incident can damage the organization’s reputation and result in regulatory fines and legal liabilities.

Recommendation

Enable “Audit Security Group Management” to generate the necessary events for detection as detailed in the setup instructions.
Deploy the following Sigma rule to detect potential Active Directory group modifications by the SYSTEM account and tune for your environment.
Investigate any event with event code 4728 where the SubjectUserSid is “S-1-5-18” as described in the overview.
Review the investigation guide outlined in the rule description for triage and analysis steps.

Kerberos Pre-authentication Disabled for User Account

hello@craftedsignal.io — Sun, 28 Jan 2024 12:00:00 +0000

This detection identifies instances where the Kerberos pre-authentication requirement is disabled for a user account within an Active Directory environment. Attackers with GenericWrite or GenericAll permissions over a target account can modify the UserAccountControl attribute to disable pre-authentication. This configuration weakens the account’s security posture, making it vulnerable to AS-REP roasting attacks, where attackers can request Kerberos tickets and crack the password offline. The activity is logged as Event ID 4738 in the Windows Security Event Logs, specifically when the NewUACList includes the USER_DONT_REQUIRE_PREAUTH flag. This poses a significant risk, especially if applied to privileged accounts, as it allows adversaries to potentially compromise credentials and escalate privileges within the domain. The detection is based on research and recommendations from Microsoft regarding Kerberos security best practices.

Attack Chain

Initial Access: An attacker gains unauthorized access to an account with sufficient privileges (e.g., Domain Admin, or an account with delegated permissions) to modify user account attributes in Active Directory.
Privilege Escalation: The attacker leverages their initial access to target a specific user account for which they intend to disable Kerberos pre-authentication.
Account Modification: The attacker modifies the UserAccountControl attribute of the target user account, specifically disabling the “Do not require pre-authentication” setting (setting the USER_DONT_REQUIRE_PREAUTH flag). This is often done using tools like Active Directory Users and Computers or PowerShell cmdlets.
Event Logging: The modification triggers a Windows Security Event Log event (Event ID 4738) on the Domain Controller, indicating that the user account attribute has been changed. The NewUACList field in the event data contains USER_DONT_REQUIRE_PREAUTH.
AS-REQ Request: The attacker crafts an AS-REQ (Authentication Service Request) to the Kerberos Key Distribution Center (KDC) for the targeted user account. Since pre-authentication is disabled, the KDC processes the request without requiring pre-authentication.
AS-REP Response: The KDC issues an AS-REP (Authentication Service Response) to the attacker, containing an encrypted Ticket Granting Ticket (TGT) for the targeted user account.
Offline Cracking: The attacker extracts the encrypted TGT from the AS-REP response and attempts to crack it offline using password cracking tools and techniques, such as hashcat or John the Ripper.
Credential Access: Upon successfully cracking the TGT, the attacker obtains the plaintext password for the targeted user account. This password can then be used for lateral movement, privilege escalation, and further malicious activities within the domain.

Impact

Compromising user accounts through AS-REP roasting can have significant consequences. Attackers can gain unauthorized access to sensitive resources, escalate privileges, and move laterally within the network. Successful AS-REP roasting leads to credential compromise, which could result in data breaches, system compromise, and disruption of services. Organizations failing to monitor and prevent Kerberos pre-authentication disabling are at an increased risk of credential theft and subsequent exploitation, potentially affecting all systems within the compromised domain.

Recommendation

Enable “Audit User Account Management” and ensure Windows Security Event Logs (specifically Event ID 4738) are being collected and forwarded to your SIEM for analysis as described in the setup instructions linked in the rule source.
Deploy the provided Sigma rule to detect Event ID 4738 events where the NewUACList contains USER_DONT_REQUIRE_PREAUTH within your environment to identify potential AS-REP roasting vulnerabilities.
Investigate any instances of disabled pre-authentication, especially on privileged accounts, following the triage steps outlined in the rule documentation.
Enforce the principle of least privilege by reviewing and restricting the privileges assigned to users and groups to prevent unauthorized modification of Active Directory user account attributes.
Monitor for suspicious Kerberos authentication patterns and investigate any anomalies that might indicate AS-REP roasting attempts.

Active Directory msPKIAccountCredentials Modification

hello@craftedsignal.io — Fri, 26 Jan 2024 18:25:00 +0000

The msPKIAccountCredentials attribute in Active Directory stores encrypted credential data, including private keys and certificates. An attacker can modify this attribute to escalate privileges by overwriting an arbitrary file. This is achieved by modifying the msPKIAccountCredentials attribute of a user object with malicious credential objects. Successful exploitation allows the attacker to gain elevated privileges within the domain. The attack leverages the Windows credential roaming feature to inject these malicious credentials. This activity is detected via event code 5136 in the Windows Security Event Logs.

Attack Chain

An attacker gains initial access to a domain-joined system, possibly through compromised credentials or phishing.
The attacker identifies a target Active Directory user account to manipulate.
The attacker crafts a malicious payload containing an encrypted credential object.
The attacker uses a tool or script (e.g., PowerShell, adsiedit.msc) to modify the target user’s msPKIAccountCredentials attribute in Active Directory.
The attacker triggers credential roaming, causing the modified attribute to be propagated to other domain-joined systems where the target user logs in.
When the target user logs in, the malicious credential object is processed, potentially overwriting a critical system file.
The attacker leverages the overwritten file to execute arbitrary code with elevated privileges.
The attacker achieves privilege escalation and gains further access to the network.

Impact

Successful modification of the msPKIAccountCredentials attribute can lead to complete domain compromise. Attackers can gain control over critical systems and data within the Active Directory environment. While the exact number of potential victims is unknown, any organization utilizing Active Directory is potentially vulnerable. This attack allows for lateral movement, data exfiltration, and potentially the deployment of ransomware.

Recommendation

Enable “Audit Directory Service Changes” to generate the necessary event logs (https://ela.st/audit-directory-service-changes).
Deploy the Sigma rule Modification of msPKIAccountCredentials in Active Directory to detect suspicious modifications of the attribute.
Review and harden Active Directory access controls, limiting which accounts can modify the msPKIAccountCredentials attribute.
Monitor event code 5136 in the Windows Security Event Logs for modifications to the msPKIAccountCredentials attribute.
Create exceptions in your SIEM for authorized administrative accounts that legitimately modify this attribute to reduce false positives as described in the “False positive analysis” section above.

Potential Kerberos Coercion via DNS-Based SPN Spoofing

hello@craftedsignal.io — Fri, 26 Jan 2024 12:00:00 +0000

This detection identifies potential Kerberos coercion attempts via DNS-based SPN spoofing on Windows systems. The technique abuses MicrosoftDNS records, specifically looking for directory-service access or creation events (event codes 4662 and 5137) involving a MicrosoftDNS record that contains a base64-encoded blob matching the pattern “UWhRCA…BAAAA”. This blob pattern corresponds to a marshaled CREDENTIAL_TARGET_INFORMATION structure, a known indicator of DNS-based SPN spoofing used in Kerberos coercion tradecraft. The goal is to detect adversaries coercing victim systems into authenticating to attacker-controlled hosts while requesting Kerberos tickets for legitimate services. This activity is typically observed within Windows Security Event Logs.

Attack Chain

The adversary gains initial access to a system with privileges to modify DNS records in Active Directory.
The attacker creates a new MicrosoftDNS record or modifies an existing one.
Within the DNS record, specifically in the AdditionalInfo or ObjectDN attributes, the attacker inserts a base64-encoded blob matching the pattern “UWhRCA…BAAAA”. This blob contains a marshaled CREDENTIAL_TARGET_INFORMATION structure.
The attacker configures the DNS record to point to an attacker-controlled host. This involves manipulating the record’s name and associated IP address.
The attacker triggers a victim system to resolve the manipulated DNS record, causing the victim to attempt Kerberos authentication with the attacker-controlled host, believing it to be a legitimate service.
The attacker intercepts the Kerberos authentication request.
The attacker relays the Kerberos ticket to a legitimate service, impersonating the victim system.
The attacker gains unauthorized access to the legitimate service using the relayed Kerberos ticket.

Impact

Successful Kerberos coercion can grant attackers unauthorized access to critical systems and services within the Active Directory domain. This may lead to privilege escalation, lateral movement, data exfiltration, and other malicious activities. The scope of impact depends on the permissions and access rights of the coerced victim system and the targeted services.

Recommendation

Enable “Audit Directory Service Access” and “Audit Directory Service Changes” Windows audit policies to ensure relevant events are logged (Setup section).
Deploy the Sigma rules provided in this brief to your SIEM to detect potential Kerberos coercion attempts via DNS-based SPN spoofing. Tune the rules based on your environment and known legitimate activity.
Investigate any alerts generated by the Sigma rules, focusing on the associated user accounts, systems, and modified DNS records (rule titles).
Restrict access to modify DNS records in Active Directory to only authorized personnel and systems to prevent unauthorized manipulation (Overview section).
Monitor Windows Security authentication events for any suspicious Kerberos activity following the modification of DNS records (Attack Chain steps 5-8).

First Time Seen Account Performing DCSync

hello@craftedsignal.io — Thu, 25 Jan 2024 12:00:00 +0000

The DCSync attack is a technique used to retrieve credential information from Active Directory, potentially leading to complete domain compromise. This attack involves initiating the Active Directory replication process, which is normally reserved for domain controllers. This detection identifies user accounts initiating this process for the first time, which can be an indicator of malicious activity. This activity is detected via Windows Security Event Logs and focuses on the identification of the initial use of replication protocols. Attackers exploit this to steal credentials or sensitive data stored within the Active Directory. This technique can be used to escalate privileges and move laterally within the network, eventually leading to data exfiltration or other malicious objectives.

Attack Chain

An attacker gains initial access to a system within the target network.
The attacker escalates privileges to obtain the necessary rights to perform DCSync. This may involve exploiting vulnerabilities or using stolen credentials.
The attacker uses a tool like Mimikatz or custom scripts to initiate the Active Directory replication process.
The tool requests replication of directory data, specifically targeting credential information. This involves using the DS-Replication-Get-Changes or similar replication-right GUIDs.
The Active Directory server responds by providing the requested data, which includes password hashes and other sensitive information.
The attacker extracts the credential information from the replicated data.
The attacker uses the extracted credentials to move laterally within the network and access other systems or data.
The attacker achieves their final objective, such as data exfiltration, ransomware deployment, or long-term persistence.

Impact

A successful DCSync attack can lead to the compromise of the entire Active Directory domain. This can result in widespread data breaches, loss of sensitive information, and significant disruption to business operations. Attackers can gain access to critical systems and data, potentially leading to financial losses, reputational damage, and legal liabilities. The number of potential victims is dependent on the size of the compromised Active Directory environment.

Recommendation

Enable “Audit Directory Service Access” to generate the necessary Windows Security Event Logs (event code 4662) as described in the setup instructions.
Deploy the Sigma rule “Detect First Time DCSync Activity” to your SIEM and tune for your environment to identify suspicious DCSync behavior.
Investigate any alerts generated by the Sigma rule, focusing on the SubjectUserSid, SubjectUserName, Properties, AccessMask, and computer_name fields in the Windows Security Event Logs.
Monitor for changes to Active Directory object permissions (5136 events) that could grant unauthorized users DCSync capabilities as outlined in the triage and analysis steps.

Detection of Sensitive LDAP Attribute Access

hello@craftedsignal.io — Fri, 19 Jan 2024 16:23:00 +0000

This detection rule identifies attempts to access sensitive attributes within Active Directory via the Lightweight Directory Access Protocol (LDAP). These attributes, including unixUserPassword, ms-PKI-AccountCredentials, and msPKI-CredentialRoamingTokens, are valuable targets for adversaries aiming to steal credentials or escalate privileges. The rule focuses on Windows Security Event Logs, specifically monitoring event code 4662 which indicates an attempt to access an object. By filtering out common benign access patterns, such as those originating from the SYSTEM account or using specific access masks, the rule aims to highlight potentially malicious activity that warrants further investigation. The original rule was created in November 2022 and updated in May 2026.

Attack Chain

An attacker gains initial access to a system within the target domain (e.g., through phishing or exploiting a public-facing application).
The attacker uses valid credentials or exploits a vulnerability to authenticate to the domain.
The attacker uses LDAP queries to enumerate Active Directory objects.
The attacker crafts specific LDAP queries to target sensitive attributes like unixUserPassword, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens.
Windows Security Event 4662 is generated, logging the access attempt with details about the user, accessed object, and properties.
The attacker exfiltrates the accessed attribute data, potentially containing password hashes, certificates, or other sensitive information.
The attacker uses the stolen credentials or certificates to impersonate other users or gain elevated privileges within the domain.

Impact

Successful exploitation can lead to the compromise of domain accounts, including privileged accounts. Attackers can use stolen credentials to move laterally within the network, access sensitive data, and disrupt business operations. Depending on the attributes accessed, this could also expose private keys and authentication certificates leading to further attacks.

Recommendation

Deploy the Sigma rule “Access to Sensitive LDAP Attributes” to your SIEM to detect access attempts to critical AD attributes (rule.name).
Enable “Audit Directory Service Access” to ensure that necessary Windows Security Event Logs (event code 4662) are generated for the Sigma rule to function (setup).
Review and tune the “Access to Sensitive LDAP Attributes” Sigma rule, creating exceptions for legitimate administrative accounts and scheduled system processes to minimize false positives (rule.note).
Implement stricter access controls and permissions for sensitive LDAP attributes within Active Directory to restrict access to only necessary personnel (rule.note).
Investigate any triggered alerts from the Sigma rule, focusing on identifying the user/process attempting access (winlog.event_data.SubjectUserSid) and the specific sensitive attribute accessed (winlog.event_data.Properties) (rule.note).

SeEnableDelegationPrivilege Assignment Detection

hello@craftedsignal.io — Wed, 03 Jan 2024 17:23:00 +0000

The SeEnableDelegationPrivilege user right, when assigned to a security principal, allows that principal to be trusted for delegation within Active Directory. Attackers can abuse this right to compromise accounts and elevate privileges by impersonating other users or services. This technique can be used for lateral movement, persistence, and ultimately, domain dominance. Defenders should monitor for the assignment of this privilege, especially to accounts that should not have it. The targeted behavior is logged as event ID 4704 in Windows Security logs. This activity is critical to monitor as it represents a powerful tool for attackers to move laterally and maintain persistence within a compromised environment.

Attack Chain

An attacker gains initial access to a compromised account with sufficient privileges to modify user rights.
The attacker assigns the SeEnableDelegationPrivilege to a target account using tools like ntrights.exe or PowerShell cmdlets.
Windows Security Event 4704 is generated, logging the privilege assignment.
The attacker modifies the target account’s attributes, such as userAccountControl or msDS-AllowedToDelegateTo, to enable delegation.
The attacker leverages Kerberos delegation to impersonate other users or services.
Using the impersonated credentials, the attacker accesses sensitive resources or performs privileged actions.
The attacker moves laterally within the network, compromising additional systems and accounts.
The attacker achieves their final objective, such as data exfiltration or domain dominance.

Impact

Successful exploitation allows attackers to compromise Active Directory accounts and elevate privileges, potentially leading to full control over the domain. The impact includes unauthorized access to sensitive data, lateral movement to critical systems, and the potential for long-term persistence. Depending on the compromised accounts, the entire organization can be at risk.

Recommendation

Enable “Audit Authorization Policy Change” to generate Windows Security Event ID 4704 (Setup instructions: https://ela.st/audit-authorization-policy-change).
Deploy the Sigma rule “Sensitive Privilege SeEnableDelegationPrivilege assigned to a Principal” to your SIEM to detect the assignment of this privilege.
Investigate any instances where SeEnableDelegationPrivilege is assigned, focusing on the targeted account and the source of the change.
Monitor for modifications to delegation-related attributes on user and computer objects.

Potential Shadow Credentials added to AD Object

hello@craftedsignal.io — Wed, 03 Jan 2024 14:57:22 +0000

The “Shadow Credentials” attack involves manipulating the msDS-KeyCredentialLink attribute in Active Directory (AD) to gain unauthorized access to user or computer accounts. Attackers can create a key pair, append the raw public key to the attribute, and authenticate as the target object. This technique allows for persistent and stealthy access, as it leverages Kerberos key trust account mapping. The original detection rule was created in January 2022 and last updated in April 2026. This attack abuses control over an object to create the shadow credentials. Defenders should monitor for modifications to the msDS-KeyCredentialLink attribute, especially those not associated with legitimate Azure AD Connect or ADFS provisioning.

Attack Chain

Initial Access: Attacker gains initial access to a system with sufficient privileges to modify Active Directory objects.
Discovery: The attacker identifies a target user or computer object within Active Directory to compromise.
Credential Access: The attacker generates a new key pair.
Privilege Escalation: The attacker modifies the msDS-KeyCredentialLink attribute of the target object to include the attacker’s public key. This requires specific permissions on the target object.
Persistence: The attacker uses the private key to authenticate as the target object, bypassing normal authentication mechanisms.
Lateral Movement: The attacker uses the compromised account to move laterally within the network, accessing resources and systems.
Impact: The attacker achieves their objective, such as data exfiltration, system compromise, or further privilege escalation.

Impact

Successful exploitation allows attackers to maintain persistent and stealthy access to Active Directory objects, potentially compromising sensitive accounts and resources. Shadow Credentials can be used to bypass multi-factor authentication and other security controls, leading to significant data breaches or system-wide compromises. Without proper monitoring and alerting, these attacks can remain undetected for extended periods.

Recommendation

Enable and monitor Windows Security Event Logs, specifically event ID 5136, for modifications to the msDS-KeyCredentialLink attribute as described in the rule description.
Deploy the provided Sigma rule to your SIEM to detect suspicious modifications to the msDS-KeyCredentialLink attribute, and tune for your environment.
Implement strict access controls and auditing on Active Directory objects, particularly those with sensitive privileges, to prevent unauthorized modifications.
Investigate any alerts generated by the Sigma rule by examining the winlog.event_data.ObjectDN, winlog.event_data.SubjectUserName, and winlog.event_data.AttributeValue fields to determine the legitimacy of the changes.
Follow the triage and analysis steps in the rule’s note field to investigate alerts.

User Added to Privileged Group in Active Directory

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Attackers often target Active Directory (AD) to gain control over a network. Adding a user account to a highly privileged group, such as Domain Admins or Enterprise Admins, is a common tactic for establishing persistence and escalating privileges. By compromising an account with the ability to manage group memberships or exploiting vulnerabilities, an attacker can add their own rogue account to a privileged group, granting them extensive control over the AD domain. This activity might go unnoticed amidst legitimate administrative actions, making it a stealthy method of maintaining unauthorized access. This is a common technique employed after initial compromise to ensure long-term access to critical systems and data. Detecting such additions requires careful monitoring of AD security logs for specific events related to group membership changes.

Attack Chain

Initial compromise of a low-privileged user account through phishing or credential theft.
Lateral movement to a system with access to Active Directory management tools.
Privilege escalation to an account with permissions to modify group memberships (e.g., leveraging exploits or credential dumping).
Use of AD management tools (e.g., Active Directory Users and Computers, PowerShell with AD module) to add the attacker-controlled user account to a privileged group, such as Domain Admins (RID 512).
The attacker logs in with the newly privileged account.
The attacker uses their elevated privileges to access sensitive data, install backdoors, or perform other malicious activities.
The attacker may attempt to remove the initially compromised account to remove traces of their activities.

Impact

Successful addition of an attacker-controlled user to a privileged AD group grants them near-total control over the domain. This can lead to widespread data breaches, ransomware deployment across the entire network, compromise of sensitive systems, and long-term disruption of business operations. The impact can extend to all domain-joined systems and resources, potentially affecting thousands of users and devices. Remediation often requires a complete rebuild of the Active Directory environment, resulting in significant downtime and financial losses.

Recommendation

Enable “Audit Security Group Management” in Active Directory to generate the necessary security events for detecting group membership changes.
Deploy the Sigma rule “User Added to Privileged Group in Active Directory” to your SIEM to detect suspicious additions to privileged groups, tuning the rule for known administrative accounts.
Monitor for unexpected use of AD management tools, such as Active Directory Users and Computers or PowerShell with the AD module, especially from unusual source hosts.
Investigate any alerts generated by the Sigma rule by verifying the legitimacy of the user adding members to the group and validating the need for the new member to have those privileges.
Regularly review the membership of privileged groups and remove any unauthorized or unnecessary accounts.

Account Configured with Never-Expiring Password

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

Attackers may abuse accounts configured with never-expiring passwords to maintain long-term access within a compromised environment. This persistence technique leverages the Active Directory setting that prevents password expiration. While sometimes legitimately used for service accounts, this configuration weakens security posture and exposes environments to credential access attacks. The rule detects Event ID 4738 (User Account Modified) with the NewUACList containing “USER_DONT_EXPIRE_PASSWORD”, and Event ID 5136 (Directory Service Changes) where the userAccountControl attribute is modified with specific values (66048 or 66080). These values indicate that the ‘Password never expires’ flag has been set on the account. Defender should monitor for such events and take immediate remediation actions.

Attack Chain

An attacker gains initial access to a domain-joined system, potentially through phishing or exploiting a public-facing application.
The attacker performs reconnaissance to identify accounts suitable for long-term persistence, focusing on privileged accounts or those with minimal monitoring.
The attacker uses compromised credentials or exploits a privilege escalation vulnerability to gain administrative access to Active Directory.
The attacker modifies the target account’s attributes using tools like net user or PowerShell cmdlets from the Active Directory module.
Specifically, the attacker sets the userAccountControl attribute to disable password expiration for the chosen account.
The attacker validates the configuration change to ensure the password expiration is disabled, allowing for persistent access.
With a never-expiring password, the attacker can maintain access to the compromised account indefinitely, even after password resets or other security measures are implemented on other accounts.

Impact

Successful exploitation allows attackers to maintain a persistent presence within the compromised domain. This can lead to data theft, further lateral movement, or disruption of services. The impact is increased if the affected account has elevated privileges, granting the attacker broader access to sensitive resources. While the number of affected organizations is unknown, the technique is applicable to any organization using Active Directory.

Recommendation

Enable and monitor Windows audit policies for User Account Management and Directory Service Changes to generate relevant events.
Deploy the Sigma rule “Account Configured with Never-Expiring Password” to your SIEM and tune for your environment.
Regularly review and audit accounts with the “Don’t Expire Password” option enabled, and enforce the use of Group Managed Service Accounts (gMSA) where appropriate.
Use the provided PowerShell command (get-aduser -filter { passwordNeverExpires -eq $true -and enabled -eq $true } | ft) to identify accounts with passwordNeverExpires enabled across the domain.

User Account ServicePrincipalName Attribute Modified

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This detection rule identifies modifications to the servicePrincipalName (SPN) attribute of user accounts within Active Directory. Attackers can exploit write privileges over a user account to configure SPNs, enabling them to perform Kerberoasting attacks. While administrators may configure SPNs legitimately, this exposes the account to potential abuse. The risk arises because user-defined passwords are often less complex than machine account passwords, making them vulnerable to cracking. The rule focuses on identifying when a user account is at increased risk due to SPN modifications, indicating potential Kerberoasting vulnerabilities. The original Elastic rule was published on 2022-02-22 and last updated on 2026-05-04.

Attack Chain

An attacker gains initial access to a system with a user account that possesses write privileges to other user accounts within Active Directory.
The attacker identifies a target user account for which they want to perform Kerberoasting.
The attacker modifies the servicePrincipalName attribute of the target user account using tools like SetSPN.exe or PowerShell.
A Kerberos client requests a ticket-granting service (TGS) ticket for the modified SPN.
The domain controller encrypts the TGS ticket with the secret key (NTLM hash) of the target user account.
The attacker extracts the encrypted TGS ticket from network traffic or the Kerberos client cache.
The attacker performs offline password cracking on the extracted TGS ticket to recover the plaintext password of the target user account using tools like Hashcat or John the Ripper.
The attacker uses the compromised credentials to gain unauthorized access to resources or perform lateral movement within the network.

Impact

Successful Kerberoasting attacks can compromise user account credentials, potentially leading to unauthorized access to sensitive resources and lateral movement within the network. If privileged accounts are compromised, attackers can gain control over critical systems and data, leading to data breaches, system disruptions, and financial losses. The number of victims depends on the permissions of the compromised account and the scope of the attacker’s access.

Recommendation

Enable and monitor “Audit Directory Service Changes” in Windows Security Event Logs to generate the events required for the detection rule (reference: https://ela.st/audit-directory-service-changes).
Deploy the “User account exposed to Kerberoasting” Sigma rule to your SIEM and tune it based on your environment.
Investigate any alerts generated by the Sigma rule, focusing on identifying the user account that performed the SPN modification and whether the modification was legitimate (reference: Sigma rule).
Implement Group Managed Service Accounts (gMSA) for services running under user accounts to ensure strong and automatically rotated passwords (reference: https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview).

Suspicious Access to LDAP Attributes

hello@craftedsignal.io — Tue, 02 Jan 2024 12:00:00 +0000

This rule identifies read access to a high number of Active Directory object attributes, which can help adversaries find vulnerabilities, elevate privileges, or collect sensitive information. The rule focuses on event code 4662, filtering for ‘Read Property’ access where the number of properties accessed is greater than or equal to 2000. The rule is designed to detect potential reconnaissance activities within an Active Directory environment, providing security teams with insights into unusual access patterns that may indicate malicious intent. This detection logic helps security teams proactively identify and respond to potential threats targeting Active Directory environments.

Attack Chain

The attacker gains initial access to a system within the target network, possibly through compromised credentials or a phishing attack (not directly covered in the provided source).
The attacker uses the compromised account to query Active Directory via LDAP.
The attacker issues a series of LDAP queries, requesting a large number of attributes for various Active Directory objects, triggering event ID 4662.
The event logs record the excessive number of read property accesses (winlog.event_data.Properties), exceeding the threshold of 2000.
The attacker analyzes the gathered information to identify potential targets, such as privileged accounts, sensitive data stores, or vulnerable systems.
The attacker attempts to elevate privileges by exploiting identified vulnerabilities or misconfigurations within Active Directory.
The attacker uses the elevated privileges to access sensitive information or move laterally within the network.
The attacker achieves their objective, such as data exfiltration or system compromise.

Impact

Successful exploitation allows attackers to gather sensitive information about the Active Directory environment, identify potential vulnerabilities, elevate privileges, and move laterally within the network. This can lead to data breaches, system compromise, and significant disruption to business operations. The number of victims and sectors targeted are dependent on the scope and objectives of the attacker.

Recommendation

Enable Audit Directory Service Access to generate the necessary events (event code 4662) as mentioned in the setup instructions.
Deploy the Sigma rule “Suspicious Access to LDAP Attributes” to your SIEM and tune the threshold (length(winlog.event_data.Properties) >= 2000) for your environment.
Review event logs for event code 4662, focusing on the winlog.event_data.Properties field, to understand which attributes were accessed.
Investigate the source machine from which the LDAP queries originated by examining the winlog.event_data.SubjectUserSid field.