[Detection Rules] Adding Documents for v8.19.11 Pre-Built Detection Rules

docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-a-scheduled-task-was-created.asciidoc

@@ -0,0 +1,130 @@
+[[prebuilt-rule-8-19-11-a-scheduled-task-was-created]]
+=== A scheduled task was created
+
+Indicates the creation of a scheduled task using Windows event logs. Adversaries can use these to establish persistence, move laterally, and/or escalate privileges.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: low
+
+*Risk score*: 21
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4698
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Persistence
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 114
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating A scheduled task was created*
+
+
+Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this feature to maintain persistence, move laterally, or escalate privileges by creating malicious tasks. The detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats. This approach helps security analysts pinpoint unauthorized task creation indicative of malicious activity.
+
+
+*Possible investigation steps*
+
+
+- Review the user account associated with the task creation to determine if it is a known and authorized user, ensuring it is not a system account by checking that the username does not end with a dollar sign.
+- Examine the task name and path in the event data to identify if it matches any known benign tasks or if it appears suspicious or unfamiliar.
+- Investigate the origin of the task creation by checking the source IP address or hostname, if available, to determine if it aligns with expected network activity.
+- Check the task's scheduled actions and triggers to understand what the task is designed to execute and when, looking for any potentially harmful or unexpected actions.
+- Correlate the task creation event with other security events or logs around the same time to identify any related suspicious activities or anomalies.
+
+
+*False positive analysis*
+
+
+- Scheduled tasks created by system accounts or computer accounts are often benign. These can be excluded by filtering out user names ending with a dollar sign, which typically represent system accounts.
+- Tasks associated with common software updates or maintenance, such as those from Hewlett-Packard or Microsoft Visual Studio, are generally non-threatening. These can be excluded by specifying their full task names in the exclusion list.
+- OneDrive update tasks are frequently triggered and are usually safe. Exclude these by using patterns that match their task names, such as those starting with "OneDrive Standalone Update Task".
+- Regularly review and update the exclusion list to include any new benign tasks that are identified over time, ensuring that the rule remains effective without generating unnecessary alerts.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
+- Terminate any suspicious scheduled tasks identified by the alert to halt any ongoing malicious activity.
+- Conduct a thorough review of the system's scheduled tasks to identify and remove any other unauthorized or suspicious tasks.
+- Restore the system from a known good backup if any malicious activity has been confirmed and has potentially compromised system integrity.
+- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited.
+- Monitor the system and network for any signs of re-infection or further unauthorized scheduled task creation.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+iam where host.os.type == "windows" and event.action == "scheduled-task-created" and
+
+ /* excluding tasks created by the computer account */
+ not user.name : "*$" and
+
+ /* TaskContent is not parsed, exclude by full taskname noisy ones */
+ not winlog.event_data.TaskName : (
+              "\\CreateExplorerShellUnelevatedTask",
+              "\\Hewlett-Packard\\HPDeviceCheck",
+              "\\Hewlett-Packard\\HP Support Assistant\\WarrantyChecker",
+              "\\Hewlett-Packard\\HP Support Assistant\\WarrantyChecker_backup",
+              "\\Hewlett-Packard\\HP Web Products Detection",
+              "\\Microsoft\\VisualStudio\\Updates\\BackgroundDownload",
+              "\\OneDrive Standalone Update Task-S-1-5-21*",
+              "\\OneDrive Standalone Update Task-S-1-12-1-*"
+ )
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Persistence
+** ID: TA0003
+** Reference URL: https://attack.mitre.org/tactics/TA0003/
+* Technique:
+** Name: Scheduled Task/Job
+** ID: T1053
+** Reference URL: https://attack.mitre.org/techniques/T1053/
+* Sub-technique:
+** Name: Scheduled Task
+** ID: T1053.005
+** Reference URL: https://attack.mitre.org/techniques/T1053/005/

docs/detections/prebuilt-rules/downloadable-packages/8-19-11/prebuilt-rule-8-19-11-access-to-a-sensitive-ldap-attribute.asciidoc

@@ -0,0 +1,183 @@
+[[prebuilt-rule-8-19-11-access-to-a-sensitive-ldap-attribute]]
+=== Access to a Sensitive LDAP Attribute
+
+Identify access to sensitive Active Directory object attributes that contains credentials and decryption keys such as unixUserPassword, ms-PKI-AccountCredentials and msPKI-CredentialRoamingTokens.
+
+*Rule type*: eql
+
+*Rule indices*: 
+
+* logs-system.security*
+* logs-windows.forwarded*
+* winlogbeat-*
+
+*Severity*: medium
+
+*Risk score*: 47
+
+*Runs every*: 5m
+
+*Searches indices from*: now-9m ({ref}/common-options.html#date-math[Date Math format], see also <<rule-schedule, `Additional look-back time`>>)
+
+*Maximum alerts per execution*: 100
+
+*References*: 
+
+* https://www.mandiant.com/resources/blog/apt29-windows-credential-roaming
+* https://social.technet.microsoft.com/wiki/contents/articles/11483.windows-credential-roaming.aspx
+* https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662
+
+*Tags*: 
+
+* Domain: Endpoint
+* OS: Windows
+* Use Case: Threat Detection
+* Tactic: Credential Access
+* Tactic: Privilege Escalation
+* Use Case: Active Directory Monitoring
+* Data Source: Active Directory
+* Data Source: Windows Security Event Logs
+* Resources: Investigation Guide
+
+*Version*: 117
+
+*Rule authors*: 
+
+* Elastic
+
+*Rule license*: Elastic License v2
+
+
+==== Investigation guide
+
+
+
+*Triage and analysis*
+
+
+> **Disclaimer**:
+> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
+
+
+*Investigating Access to a Sensitive LDAP Attribute*
+
+
+LDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, facilitating credential theft or privilege escalation. The detection rule identifies unauthorized access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce noise, thus highlighting potential security threats.
+
+
+*Possible investigation steps*
+
+
+- Review the event logs for event code 4662 to identify the specific user or process attempting to access the sensitive LDAP attributes.
+- Check the winlog.event_data.SubjectUserSid to determine the identity of the user or service account involved in the access attempt, excluding the well-known SID S-1-5-18 (Local System).
+- Analyze the winlog.event_data.Properties field to confirm which sensitive attribute was accessed, such as unixUserPassword, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens.
+- Investigate the context of the access attempt by correlating the event with other logs or alerts around the same timestamp to identify any suspicious patterns or activities.
+- Verify the legitimacy of the access by checking if the user or process has a valid reason or permission to access the sensitive attributes, considering the organization's access control policies.
+- Assess the potential impact of the access attempt on the organization's security posture, focusing on credential theft or privilege escalation risks.
+- Document findings and, if necessary, escalate the incident to the appropriate security team for further action or remediation.
+
+
+*False positive analysis*
+
+
+- Access by legitimate administrative accounts: Regular access by system administrators to sensitive LDAP attributes can trigger alerts. To manage this, create exceptions for known administrative accounts by excluding their SIDs from the detection rule.
+- Scheduled system processes: Automated tasks or system processes that require access to certain LDAP attributes may cause false positives. Identify these processes and exclude their specific event codes or AccessMasks if they are consistently benign.
+- Service accounts: Service accounts that perform routine directory operations might access sensitive attributes as part of their normal function. Exclude these accounts by adding their SIDs to the exception list to prevent unnecessary alerts.
+- Monitoring tools: Security or monitoring tools that scan directory attributes for compliance or auditing purposes can generate false positives. Whitelist these tools by excluding their event sources or specific actions from the detection criteria.
+
+
+*Response and remediation*
+
+
+- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration.
+- Conduct a thorough review of the access logs to identify any unauthorized users or systems that accessed the sensitive LDAP attributes.
+- Reset passwords and revoke any potentially compromised credentials associated with the affected accounts, focusing on those with access to sensitive attributes.
+- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach.
+- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to access sensitive LDAP attributes.
+- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel.
+- Conduct a post-incident analysis to identify any gaps in security controls and update policies or procedures to prevent similar incidents in the future.
+
+==== Setup
+
+
+
+*Setup*
+
+
+The 'Audit Directory Service Access' logging policy must be configured for (Success, Failure).
+Steps to implement the logging policy with Advanced Audit Configuration:
+
+```
+Computer Configuration >
+Policies >
+Windows Settings >
+Security Settings >
+Advanced Audit Policies Configuration >
+Audit Policies >
+DS Access >
+Audit Directory Service Access (Success,Failure)
+```
+
+
+==== Rule query
+
+
+[source, js]
+----------------------------------
+any where host.os.type == "windows" and event.code == "4662" and
+
+  not winlog.event_data.SubjectUserSid : "S-1-5-18" and
+
+  winlog.event_data.Properties : (
+   /* unixUserPassword */
+  "*612cb747-c0e8-4f92-9221-fdd5f15b550d*",
+
+  /* ms-PKI-AccountCredentials */
+  "*b8dfa744-31dc-4ef1-ac7c-84baf7ef9da7*",
+
+  /*  ms-PKI-DPAPIMasterKeys */
+  "*b3f93023-9239-4f7c-b99c-6745d87adbc2*",
+
+  /* msPKI-CredentialRoamingTokens */
+  "*b7ff5a38-0818-42b0-8110-d3d154c97f24*"
+  ) and
+
+  /*
+   Excluding noisy AccessMasks
+   0x0 undefined and 0x100 Control Access
+   https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4662
+   */
+  not winlog.event_data.AccessMask in ("0x0", "0x100")
+
+----------------------------------
+
+*Framework*: MITRE ATT&CK^TM^
+
+* Tactic:
+** Name: Credential Access
+** ID: TA0006
+** Reference URL: https://attack.mitre.org/tactics/TA0006/
+* Technique:
+** Name: OS Credential Dumping
+** ID: T1003
+** Reference URL: https://attack.mitre.org/techniques/T1003/
+* Technique:
+** Name: Unsecured Credentials
+** ID: T1552
+** Reference URL: https://attack.mitre.org/techniques/T1552/
+* Sub-technique:
+** Name: Private Keys
+** ID: T1552.004
+** Reference URL: https://attack.mitre.org/techniques/T1552/004/
+* Tactic:
+** Name: Privilege Escalation
+** ID: TA0004
+** Reference URL: https://attack.mitre.org/tactics/TA0004/
+* Technique:
+** Name: Valid Accounts
+** ID: T1078
+** Reference URL: https://attack.mitre.org/techniques/T1078/
+* Sub-technique:
+** Name: Domain Accounts
+** ID: T1078.002
+** Reference URL: https://attack.mitre.org/techniques/T1078/002/