Potential Shadow Credentials added to AD Object

 1[metadata]
 2creation_date = "2022/01/26"
 3integration = ["system", "windows"]
 4maturity = "production"
 5updated_date = "2024/10/28"
 6min_stack_version = "8.14.0"
 7min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration."
 8
 9[rule]
10author = ["Elastic"]
11description = """
12Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object.
13Attackers can abuse control over the object and create a key pair, append to raw public key in the attribute, and obtain
14persistent and stealthy access to the target user or computer object.
15"""
16false_positives = [
17    """
18    Modifications in the msDS-KeyCredentialLink attribute can be done legitimately by the Azure AD Connect
19    synchronization account or the ADFS service account. These accounts can be added as Exceptions.
20    """,
21]
22from = "now-9m"
23index = ["winlogbeat-*", "logs-system.*", "logs-windows.*"]
24language = "kuery"
25license = "Elastic License v2"
26name = "Potential Shadow Credentials added to AD Object"
27note = """## Triage and analysis
28
29### Investigating Potential Shadow Credentials added to AD Object
30
31The msDS-KeyCredentialLink is an Active Directory (AD) attribute that links cryptographic certificates to a user or computer for domain authentication.
32
33Attackers with write privileges on this attribute over an object can abuse it to gain access to the object or maintain persistence. This means they can authenticate and perform actions on behalf of the exploited identity, and they can use Shadow Credentials to request Ticket Granting Tickets (TGTs) on behalf of the identity.
34
35#### Possible investigation steps
36
37- Identify whether Windows Hello for Business (WHfB) and/or Azure AD is used in the environment.
38  - Review the event ID 4624 for logon events involving the subject identity (`winlog.event_data.SubjectUserName`).
39    - Check whether the `source.ip` is the server running Azure AD Connect.
40- Contact the account and system owners and confirm whether they are aware of this activity.
41- Investigate other alerts associated with the user/host during the past 48 hours.
42- Review the event IDs 4768 and 4769 for suspicious ticket requests involving the modified identity (`winlog.event_data.ObjectDN`).
43  - Extract the source IP addresses from these events and use them as indicators of compromise (IoCs) to investigate whether the host is compromised and to scope the attacker's access to the environment.
44
45### False positive analysis
46
47- Administrators might use custom accounts on Azure AD Connect. If this is the case, make sure the account is properly secured. You can also create an exception for the account if expected activity makes too much noise in your environment.
48
49### Response and remediation
50
51- Initiate the incident response process based on the outcome of the triage.
52- Investigate credential exposure on systems compromised or used by the attacker to ensure all compromised accounts are identified. Reset passwords for these accounts and other potentially compromised credentials, such as email, business systems, and web services.
53  - Remove the Shadow Credentials from the object.
54- Investigate how the attacker escalated privileges and identify systems they used to conduct lateral movement. Use this information to determine ways the attacker could regain access to the environment.
55- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.
56- Using the incident response data, update logging and audit policies to improve the mean time to detect (MTTD) and the mean time to respond (MTTR).
57"""
58references = [
59    "https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab",
60    "https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials",
61    "https://github.com/OTRF/Set-AuditRule",
62    "https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/",
63]
64risk_score = 73
65rule_id = "79f97b31-480e-4e63-a7f4-ede42bf2c6de"
66setup = """## Setup
67
68The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).
69Steps to implement the logging policy with Advanced Audit Configuration:

1
2The above policy does not cover User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.
3As this specifies the msDS-KeyCredentialLink Attribute GUID, it is expected to be low noise.

 1"""
 2severity = "high"
 3tags = [
 4    "Domain: Endpoint",
 5    "OS: Windows",
 6    "Use Case: Threat Detection",
 7    "Tactic: Credential Access",
 8    "Data Source: Active Directory",
 9    "Resources: Investigation Guide",
10    "Use Case: Active Directory Monitoring",
11    "Data Source: System",
12]
13timestamp_override = "event.ingested"
14type = "query"
15
16query = '''
17event.action:("Directory Service Changes" or "directory-service-object-modified") and event.code:"5136" and
18 winlog.event_data.AttributeLDAPDisplayName:"msDS-KeyCredentialLink" and winlog.event_data.AttributeValue :B\:828* and
19 not winlog.event_data.SubjectUserName: MSOL_*
20'''
21
22
23[[rule.threat]]
24framework = "MITRE ATT&CK"
25[[rule.threat.technique]]
26id = "T1556"
27name = "Modify Authentication Process"
28reference = "https://attack.mitre.org/techniques/T1556/"
29
30
31[rule.threat.tactic]
32id = "TA0006"
33name = "Credential Access"
34reference = "https://attack.mitre.org/tactics/TA0006/"