Detection: Windows Modify Registry Risk Behavior

Description

The following analytic identifies instances where three or more distinct registry modification events associated with MITRE ATT&CK Technique T1112 are detected. It leverages data from the Risk data model in Splunk, focusing on registry-related sources and MITRE technique annotations. This activity is significant because multiple registry modifications can indicate an attempt to persist, hide malicious configurations, or erase forensic evidence. If confirmed malicious, this behavior could allow attackers to maintain persistent access, execute malicious code, and evade detection, posing a severe threat to the integrity and security of the affected host.

Search

1
2| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as lastTime sum(All_Risk.calculated_risk_score) as risk_score, count(All_Risk.calculated_risk_score) as risk_event_count, values(All_Risk.annotations.mitre_attack.mitre_tactic_id) as annotations.mitre_attack.mitre_tactic_id, dc(All_Risk.annotations.mitre_attack.mitre_tactic_id) as mitre_tactic_id_count, values(All_Risk.annotations.mitre_attack.mitre_technique_id) as annotations.mitre_attack.mitre_technique_id, dc(All_Risk.annotations.mitre_attack.mitre_technique_id) as mitre_technique_id_count, values(All_Risk.tag) as tag, values(source) as source, dc(source) as source_count from datamodel=Risk.All_Risk where source IN ("*registry*") All_Risk.annotations.mitre_attack.mitre_technique_id IN ("*T1112*") by All_Risk.risk_object All_Risk.risk_object_type All_Risk.annotations.mitre_attack.mitre_tactic 
3| `drop_dm_object_name(All_Risk)` 
4| `security_content_ctime(firstTime)` 
5| `security_content_ctime(lastTime)` 
6| where source_count >= 3 
7| `windows_modify_registry_risk_behavior_filter`

Data Source

Macros Used

Annotations

Default Configuration

This detection is configured by default in Splunk Enterprise Security to run with the following settings:

Implementation

Splunk Enterprise Security is required to utilize this correlation. In addition, modify the source_count value to your environment. In our testing, a count of 4 or 5 was decent in a lab, but the number may need to be increased base on internal testing. In addition, based on false positives, modify any analytics to be anomaly and lower or increase risk based on organization importance.

Known False Positives

False positives will be present based on many factors. Tune the correlation as needed to reduce too many triggers.

Associated Analytic Story

• Windows Registry Abuse

Risk Based Analytics (RBA)

References

• https://www.splunk.com/en_us/blog/security/do-not-cross-the-redline-stealer-detections-and-analysis.html

• https://www.splunk.com/en_us/blog/security/asyncrat-crusade-detections-and-defense.html

• https://www.splunk.com/en_us/blog/security/from-registry-with-love-malware-registry-abuses.html

• https://www.splunk.com/en_us/blog/security/-applocker-rules-as-defense-evasion-complete-analysis.html

Detection Testing

Replay any dataset to Splunk Enterprise by using our replay.py tool or the UI. Alternatively you can replay a dataset into a Splunk Attack Range

Source: GitHub | Version: 2