Branch was auto-updated.

detections/endpoint/suspicious_event_log_service_behavior.yml

@@ -0,0 +1,58 @@
+name: Suspicious Event Log Service Behavior
+id: 2b85aa3d-f5f6-4c2e-a081-a09f6e1c2e40
+version: 1
+date: '2021-06-17'
+author: Mauricio Velazco, Splunk
+type: batch
+datamodel: []
+description: The following analytic utilizes Windows Event ID 1100 to identify when
+  Windows event log service is shutdown. Note that this is a voluminous analytic
+  that will require tuning or restricted to specific endpoints based on criticality.
+  This event generates every time Windows Event Log service has shut down. It also
+  generates during normal system shutdown. During triage, based on time of day and
+  user, determine if this was planned. If not planned, follow through with reviewing
+  parallel alerts and other data sources to determine what else may have occurred.
+search: (`wineventlog_security` EventCode=1100) | stats count min(_time) as firstTime
+  max(_time) as lastTime by dest Message EventCode | `security_content_ctime(firstTime)`
+  | `security_content_ctime(lastTime)` | `suspicious_event_log_service_behavior_filter`
+how_to_implement: To successfully implement this search, you need to be ingesting
+  Windows event logs from your hosts. In addition, the Splunk Windows TA is needed.
+known_false_positives: It is possible the Event Logging service gets shut down due
+  to system errors or legitimately administration tasks. Filter as needed.
+references:
+- https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-1100
+- https://www.ired.team/offensive-security/defense-evasion/disabling-windows-event-logs-by-suspending-eventlog-service-threads
+- https://attack.mitre.org/techniques/T1070/001/
+- https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1070.001/T1070.001.md
+tags:
+  analytic_story:
+  - Windows Log Manipulation
+  - Ransomware
+  - Clop Ransomware
+  asset_type: Endpoint
+  cis20:
+  - CIS 3
+  - CIS 5
+  - CIS 6
+  dataset:
+  - https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.001/atomic_red_team/windows-security.log
+  kill_chain_phases:
+  - Actions on Objectives
+  mitre_attack_id:
+  - T1070.001
+  nist:
+  - DE.DP
+  - PR.IP
+  - PR.AC
+  - PR.AT
+  - DE.AE
+  product:
+  - Splunk Enterprise
+  - Splunk Enterprise Security
+  - Splunk Cloud
+  required_fields:
+  - _time
+  - EventCode
+  - dest
+  security_domain: endpoint
+  automated_detection_testing: passed

detections/endpoint/windows_event_log_cleared.yml

@@ -1,21 +1,28 @@
 name: Windows Event Log Cleared
 id: ad517544-aff9-4c96-bd99-d6eb43bfbb6a
-version: 4
+version: 6
 date: '2020-07-06'
-author: Rico Valdez, Splunk
+author: Rico Valdez, Michael Haag, Splunk
 type: batch
 datamodel: []
-description: This search looks for Windows events that indicate one of the Windows
-  event logs has been purged.
-search: (`wineventlog_security` (EventCode=1102 OR EventCode=1100)) OR (`wineventlog_system`
-  EventCode=104) | stats count min(_time) as firstTime max(_time) as lastTime by EventCode
-  dest | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`
-  | `windows_event_log_cleared_filter`
+description: The following analytic utilizes Windows Security Event ID 1102 or System log event 104 to identify when
+  a Windows event log is cleared. Note that this analytic will require tuning or restricted to specific endpoints based on criticality.
+  During triage, based on time of day and user, determine if this was planned. If not planned, follow through with reviewing
+  parallel alerts and other data sources to determine what else may have occurred.
+search: '(`wineventlog_security` EventCode=1102) OR (`wineventlog_system` EventCode=104) 
+  | stats count min(_time) as firstTime max(_time) as lastTime by dest Message EventCode
+  | `security_content_ctime(firstTime)` 
+  | `security_content_ctime(lastTime)`
+  | `windows_event_log_cleared_filter`'
 how_to_implement: To successfully implement this search, you need to be ingesting
-  Windows event logs from your hosts.
+  Windows event logs from your hosts. In addition, the Splunk Windows TA is needed.
 known_false_positives: It is possible that these logs may be legitimately cleared
-  by Administrators.
-references: []
+  by Administrators. Filter as needed.
+references:
+  - https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-1102
+  - https://www.ired.team/offensive-security/defense-evasion/disabling-windows-event-logs-by-suspending-eventlog-service-threads
+  - https://attack.mitre.org/techniques/T1070/001/
+  - https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1070.001/T1070.001.md
 tags:
   analytic_story:
   - Windows Log Manipulation

dist/escu/default/macros.conf

@@ -1803,6 +1803,10 @@ description = Update this macro to limit the output results to filter out false
 definition = search *
 description = Update this macro to limit the output results to filter out false positives. 
 
+[suspicious_event_log_service_behavior]
+definition = search *
+description = Update this macro to limit the output results to filter out false positives. 
+
 [windows_security_account_manager_stopped_filter]
 definition = search *
 description = Update this macro to limit the output results to filter out false positives. 

tests/endpoint/suspicious_event_log_service_behavior.test.yml

@@ -0,0 +1,13 @@
+name: Suspicious Event Log Service Behavior
+tests:
+- name: Suspicious Event Log Service Behavior
+  file: endpoint/suspicious_event_log_service_behavior.yml
+  pass_condition: '| stats count | where count > 0'
+  earliest_time: '-24h'
+  latest_time: 'now'
+  attack_data:
+  - file_name: windows-security.log
+    data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1070.001/atomic_red_team/windows-security.log
+    source: WinEventLog:Security
+    sourcetype: WinEventLog
+    update_timestamp: True