Disabling Remote User Account Control

Original Source: [splunk source]
Name:Disabling Remote User Account Control
id:bbc644bc-37df-4e1a-9c88-ec9a53e2038c
version:10
date:2025-02-10
author:David Dorsey, Patrick Bareiss, Splunk
status:production
type:TTP
Description:The following analytic identifies modifications to the registry key that controls the enforcement of Windows User Account Control (UAC). It detects changes to the registry path `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA` where the value is set to `0x00000000`. This activity is significant because disabling UAC can allow unauthorized changes to the system without user consent, potentially leading to privilege escalation. If confirmed malicious, an attacker could gain elevated privileges, making it easier to execute further attacks or maintain persistence within the environment.
Data_source:
  • -Sysmon EventID 13
search:| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime FROM datamodel=Endpoint.Registry where Registry.registry_path=*\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\EnableLUA* Registry.registry_value_data="0x00000000" by Registry.action Registry.dest Registry.process_guid Registry.process_id Registry.registry_hive Registry.registry_path Registry.registry_key_name Registry.registry_value_data Registry.registry_value_name Registry.registry_value_type Registry.status Registry.user Registry.vendor_product
| `drop_dm_object_name(Registry)`
| `disabling_remote_user_account_control_filter`


how_to_implement:To successfully implement this search, you must be ingesting data that records registry activity from your hosts to populate the endpoint data model in the registry node. This is typically populated via endpoint detection-and-response product, such as Carbon Black, or via other endpoint data sources, such as Sysmon. The data used for this search is typically generated via logs that report registry modifications.
known_false_positives:This registry key may be modified via administrators to implement a change in system policy. This type of change should be a very rare occurrence.
References:
drilldown_searches:
name:'View the detection results for - "$user$" and "$dest$"'
search:'%original_detection_search% | search user = "$user$" dest = "$dest$"'
earliest_offset:'$info_min_time$'
latest_offset:'$info_max_time$'
name:'View risk events for the last 7 days for - "$user$" and "$dest$"'
search:'| from datamodel Risk.All_Risk | search normalized_risk_object IN ("$user$", "$dest$") starthoursago=168 | stats count min(_time) as firstTime max(_time) as lastTime values(search_name) as "Search Name" values(risk_message) as "Risk Message" values(analyticstories) as "Analytic Stories" values(annotations._all) as "Annotations" values(annotations.mitre_attack.mitre_tactic) as "ATT&CK Tactics" by normalized_risk_object | `security_content_ctime(firstTime)` | `security_content_ctime(lastTime)`'
earliest_offset:'$info_min_time$'
latest_offset:'$info_max_time$'
tags:
  analytic_story:
    - 'Windows Defense Evasion Tactics'
    - 'Suspicious Windows Registry Activities'
    - 'Remcos'
    - 'Windows Registry Abuse'
    - 'Azorult'
    - 'AgentTesla'
  asset_type:Endpoint
  mitre_attack_id:
    - 'T1548.002'
  product:
    - 'Splunk Enterprise'
    - 'Splunk Enterprise Security'
    - 'Splunk Cloud'
  security_domain:endpoint

tests:
name:'True Positive Test'
 attack_data:
  data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1548.002/atomic_red_team/windows-sysmon.log
  source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
  sourcetype: XmlWinEventLog
manual_test:None