[Security Solution] Validation for Invalid Field Inputs in Advanced Settings Is Bypassed

[pborgonovi]

Summary

When editing a prebuilt rule in the Advanced Settings tab, providing invalid values for the fields “Rule name override” and “Timestamp override” causes the fields to turn red, indicating an error. However, the system incorrectly allows the rule to be saved:

• The rule is marked as “Modified Elastic Rule” after saving.
• The invalid values are not applied to the rule, and the original values remain intact.
• api/detection_engine/rules?id=<rule_id> response indicates that the rule has been customized, with the rule_source.is_customized field set to true, despite the invalid changes not being applied.

Kibana/Elasticsearch Stack version:

8.x

Current branch: 8.x  
Latest commit: 26bfdaef960 - [8.x] feat: update OTEL Node.js metrics dashboard (#199353) (#200810)  
Remote tracking: origin/8.x  
Status relative to remote: up to date (no pending commits)  

Steps to reproduce:

1. Open Kibana and navigate to the Rule Management page.
2. Edit a prebuilt rule and go to the Advanced Settings tab.
3. Enter invalid values in the following fields:
   a. Rule name override: Provide a value that does not exist in the schema.
   b. Timestamp override: Enter a non-timestamp field or invalid string.
4. Observe the fields turning red, indicating validation errors.
5. Click Save changes.

Current behavior:

• The UI allows the user to save the rule despite the validation errors.
• The rule is marked as “Modified Elastic Rule” in the UI.
• The API response contains the values below indicating that the rule is considered customized, even though the invalid changes were not applied.

"rule_source": {
    "type": "external",
    "is_customized": true
}

Expected behavior:

• The system should block saving the rule until all validation errors are resolved.
• The rule_source.is_customized field should only be set to true if valid changes are applied to the rule.

Screenshots

Screen.Recording.2024-11-19.at.3.24.32.PM.mov

Details

Provide logs and/or server output (if relevant):

{
    "id": "a5e9c567-b41e-44fc-ad2b-63e03dcb7a79",
    "updated_at": "2024-11-19T23:24:56.975Z",
    "updated_by": "elastic",
    "created_at": "2024-11-19T18:54:48.654Z",
    "created_by": "elastic",
    "name": "Potential Shadow Credentials added to AD Object",
    "tags": [
        "Domain: Endpoint",
        "OS: Windows",
        "Use Case: Threat Detection",
        "Tactic: Credential Access",
        "Data Source: Active Directory",
        "Resources: Investigation Guide",
        "Use Case: Active Directory Monitoring",
        "Data Source: System"
    ],
    "interval": "5m",
    "enabled": false,
    "revision": 1,
    "description": "Identify the modification of the msDS-KeyCredentialLink attribute in an Active Directory Computer or User Object. Attackers can abuse control over the object and create a key pair, append to raw public key in the attribute, and obtain persistent and stealthy access to the target user or computer object.",
    "risk_score": 73,
    "severity": "high",
    "note": "## Triage and analysis\n\n### Investigating Potential Shadow Credentials added to AD Object\n\nThe msDS-KeyCredentialLink is an Active Directory (AD) attribute that links cryptographic certificates to a user or computer for domain authentication.\n\nAttackers 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.\n\n#### Possible investigation steps\n\n- Identify whether Windows Hello for Business (WHfB) and/or Azure AD is used in the environment.\n  - Review the event ID 4624 for logon events involving the subject identity (`winlog.event_data.SubjectUserName`).\n    - Check whether the `source.ip` is the server running Azure AD Connect.\n- Contact the account and system owners and confirm whether they are aware of this activity.\n- Investigate other alerts associated with the user/host during the past 48 hours.\n- Review the event IDs 4768 and 4769 for suspicious ticket requests involving the modified identity (`winlog.event_data.ObjectDN`).\n  - 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.\n\n### False positive analysis\n\n- 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.\n\n### Response and remediation\n\n- Initiate the incident response process based on the outcome of the triage.\n- 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.\n  - Remove the Shadow Credentials from the object.\n- 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.\n- Determine the initial vector abused by the attacker and take action to prevent reinfection through the same vector.\n- 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).\n",
    "license": "Elastic License v2",
    "output_index": "",
    "meta": {
        "from": "4m",
        "kibana_siem_app_url": ""
    },
    "timestamp_override": "event.ingested",
    "timestamp_override_fallback_disabled": false,
    "author": [
        "Elastic"
    ],
    "false_positives": [
        "Modifications in the msDS-KeyCredentialLink attribute can be done legitimately by the Azure AD Connect synchronization account or the ADFS service account. These accounts can be added as Exceptions."
    ],
    "from": "now-540s",
    "rule_id": "79f97b31-480e-4e63-a7f4-ede42bf2c6de",
    "max_signals": 100,
    "risk_score_mapping": [],
    "severity_mapping": [],
    "threat": [
        {
            "framework": "MITRE ATT&CK",
            "tactic": {
                "id": "TA0006",
                "name": "Credential Access",
                "reference": "https://attack.mitre.org/tactics/TA0006/"
            },
            "technique": [
                {
                    "id": "T1556",
                    "name": "Modify Authentication Process",
                    "reference": "https://attack.mitre.org/techniques/T1556/"
                }
            ]
        }
    ],
    "to": "now",
    "references": [
        "https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab",
        "https://www.thehacker.recipes/ad/movement/kerberos/shadow-credentials",
        "https://github.com/OTRF/Set-AuditRule",
        "https://cyberstoph.org/posts/2022/03/detecting-shadow-credentials/"
    ],
    "version": 110,
    "exceptions_list": [],
    "immutable": true,
    "rule_source": {
        "type": "external",
        "is_customized": true
    },
    "related_integrations": [
        {
            "package": "system",
            "version": "^1.6.4"
        },
        {
            "package": "windows",
            "version": "^1.5.0"
        }
    ],
    "required_fields": [
        {
            "name": "event.action",
            "type": "keyword",
            "ecs": true
        },
        {
            "name": "event.code",
            "type": "keyword",
            "ecs": true
        },
        {
            "name": "winlog.event_data.AttributeLDAPDisplayName",
            "type": "unknown",
            "ecs": false
        },
        {
            "name": "winlog.event_data.AttributeValue",
            "type": "unknown",
            "ecs": false
        },
        {
            "name": "winlog.event_data.SubjectUserName",
            "type": "keyword",
            "ecs": false
        }
    ],
    "setup": "## Setup\n\nThe 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure).\nSteps to implement the logging policy with Advanced Audit Configuration:\n\n```\nComputer Configuration >\nPolicies >\nWindows Settings >\nSecurity Settings >\nAdvanced Audit Policies Configuration >\nAudit Policies >\nDS Access >\nAudit Directory Service Changes (Success,Failure)\n```\n\nThe above policy does not cover User objects, so we need to set up an AuditRule using https://github.com/OTRF/Set-AuditRule.\nAs this specifies the msDS-KeyCredentialLink Attribute GUID, it is expected to be low noise.\n\n```\nSet-AuditRule -AdObjectPath 'AD:\\CN=Users,DC=Domain,DC=com' -WellKnownSidType WorldSid -Rights WriteProperty -InheritanceFlags Children -AttributeGUID 5b47d60f-6090-40b2-9f37-2a4de88f3063 -AuditFlags Success\n```\n",
    "type": "query",
    "language": "kuery",
    "index": [
        "winlogbeat-*",
        "logs-system.*",
        "logs-windows.*"
    ],
    "query": "event.action:(\"Directory Service Changes\" or \"directory-service-object-modified\") and event.code:\"5136\" and\n winlog.event_data.AttributeLDAPDisplayName:\"msDS-KeyCredentialLink\" and winlog.event_data.AttributeValue :B\\:828* and\n not winlog.event_data.SubjectUserName: MSOL_*\n",
    "filters": [],
    "actions": []
}

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[elasticmachine]

Pinging @elastic/security-detection-rule-management (Team:Detection Rule Management)

[banderror]

@dplumlee Please prioritize fixing this in the next 2 weeks. We should also reflect this use case in the test plan for the customization workflow you're working on and cover it with tests.

[dplumlee]

I'm not able to reproduce this bug on the most recent build of main or 8.x, could you validate this @pborgonovi?

The rule is able to be saved with the fields showing invalid but those are existing problems having to do with the rule edit form - we don't appear to set the rule to "Modified" on save even when those fields are invalid. (Which might be what we want for prebuilt rules the same way we allow for the rule to still save with query warnings for EQL rules)

This could be an artifact of this issue before it was fixed.

[pborgonovi]

Hey @dplumlee

I retested with most recent build of 8.17 and validate the issue is not occurring, as you mentioned. Rule is kept on initial state.

Screen.Recording.2024-11-27.at.10.33.12.AM.mov

I'm closing this as working as expected.